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1.1  Introduction. 


The  theory  of  domains  was  established  in  order  to  have  appropriate  spaces  on  which  to  define 
semantic  functions  for  the  denotational  approach  to  programming-language  semantics.  There  were 
two  needs:  first,  there  had  to  be  spaces  of  several  different  types  available  to  mirror  both  the 
type  distinctions  in  the  languages  and  also  to  allow  for  different  kinds  of  semantical  constructs — 
especially  in  dealing  with  languages  with  side  effects;  and  second,  the  theory  had  to  account  for 
computability  properties  of  functions — if  the  theory  was  going  to  be  realistic.  The  first  need  is 
complicated  by  the  fact  that  types  can  be  both  compound  (or  made  up  from  other  types)  and 
recursive  (or  self-referential),  and  that  a  high-level  language  of  types  and  a  suitable  semantics  of 
types  is  required  to  explain  what  is  going  on.  The  second  need  is  complicated  by  these  complications 
of  the  semantical  definitions  and  the  fact  that  it  has  to  be  checked  that  the  level  of  abstraction 
reached  still  allows  a  precise  definition  of  computability. 

This  degree  of  abstraction  had  only  partly  been  served  by  the  state  of  recursion  theory  in  1969 
when  the  senior  author  of  this  report  started  working  on  denotational  semantics  in  collaboration 
with  Christopher  Strachey.  In  order  to  fix  some  mathematical  precision,  he  took  over  some  defini¬ 
tions  of  recursion  theorists  such  as  Kleene,  Nerode,  Davis,  and  Platek  and  gave  an  approach  to  a 
simple  type  theory  of  higher-type  functionals.  It  was  only  after  giving  an  abstract  characterization 
of  the  spaces  obtained  (through  the  construction  of  bases)  that  he  realized  that  recursive  defini¬ 
tions  of  types  could  be  accommodated  as  well — and  that  the  recursive  definitions  could  incorporate 
function  spaces  as  well.  Though  it  was  not  the  original  intention  to  find  semantics  of  the  so-called 
untyped  A-calculus,  such  a  semantics  emerged  along  with  many  ways  of  interpreting  a  very  large 
variety  of  languages. 

A  large  number  of  people  have  made  essential  contributions  to  the  subsequent  developments, 
and  they  have  shown  in  particular  that  domain  theory  is  not  one  monolithic  theory,  but  that 
there  are  several  different  kinds  of  constructions  giving  classes  of  domains  appropriate  for  different 
mixtures  of  constructs.  The  story  is,  in  fact,  far  from  finished  even  today.  In  this  report  we  will 
only  be  able  to  touch  on  a  few  of  the  possibilities,  but  we  give  pointers  to  the  literature.  Also, 
we  have  attempted  to  explain  the  foundations  in  an  elementary  way — avoiding  heavy  prerequisites 
(such  as  category  theory)  but  still  maintaining  some  level  of  abstraction — with  the  hope  that  such 
an  introduction  will  aid  the  reader  in  going  further  into  the  theory. 

The  chapter  is  divided  into  seven  sections.  In  the  second  section  we  introduce  a  simple  class 
of  ordered  structures  and  discuss  the  idea  of  fixed  points  of  continuous  functions  as  meanings  for 
recursive  programs.  In  the  third  section  we  discuss  computable  functions  and  effective  presentations. 
The  fourth  section  defines  some  of  the  operators  and  functions  which  are  used  in  semantic  definitions 
and  describes  their  distinguishing  characteristics.  A  special  collection  of  such  operators  called 
powerdomains  are  discussed  in  the  fifth  section.  Closure  problems  with  respect  to  the  convex 
powerdomain  motivate  the  introduction  of  the  class  of  bifinite  domains  which  we  describe  in  the 
sixth  section.  The  seventh  section  deals  with  the  important  issue  of  obtaining  fixed  points  for 
(certain)  operators  on  domains.  We  illustrate  the  method  by  showing  how  to  find  domains  D 
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satisfying  isomorphisms  such  asD=iD'xD2*D~>D  and  D  2f  N  +  (D  — ►  D).  (Such  domains  are 
models  of  the  above-mentioned  untyped  A-calculus.) 

Many  of  the  proofs  for  results  presented  below  are  sketched  or  omitted.  With  a  few  exceptions, 
the  enthusiastic  reader  should  be  able  to  fill  in  proofs  without  great  difficulty.  For  the  exceptions 
we  provide  a  warning  and  a  pointer  to  the  literature. 
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1.2  Recursive  definitions  of  functions. 

It  is  the  essential  purpose  of  the  theory  of  domains  to  study  classes  of  spaces  which  may  be  used 
to  give  semantics  for  recursive  definitions.  In  this  section  we  discuss  spaces  having  certain  kinds 
of  limits  in  which  a  useful  fixed  point  existence  theorem  holds.  We  will  briefly  indicate  how  this 
theorem  can  be  used  in  semantic  specification. 

1.2.1  Cpo’s  and  the  Fixed  Point  Theorem. 

A  partially  ordered  set  is  a  set  D  together  with  a  binary  relation  C  which  is  reflexive,  anti-symmetric 
and  transitive.  We  will  usually  write  D  for  the  pair  (j D,C)  and  abbreviate  the  phrase  “partially 
ordered  set”  with  the  term  “poset”.  A  subset  M  C  D  is  directed  if,  for  every  finite  set  u  C  .V/, 
there  is  an  upper  bound  x  £  M  for  u.  A  poset  D  is  complete  (and  hence  a  cpo)  if  every  directed 
subset  M  C  D  has  a  least  upper  bound  \_\M  and  there  is  a  least  element  i.#  in  D.  When  D  is 
understood  from  context,  the  subscript  on  ±£>  will  usually  be  dropped. 

It  is  not  hard  to  see  that  any  finite  poset.  that  has  a  least  element  is  a  cpo.  The  easiest  such 
example  is  the  one  point  poset  I.  Another  easy  example  which  will  come  up  later  is  the  poset  0 
which  has  two  distinct  elements  T  and  J.  with  1CT.  The  truth  value  cpo  T  is  the  poset  which 
has  three  distinct  points,  _L,  true, false,  where  ±  C  true  and  J.  C  false  (see  Figure  1.1).  To  get 
an  example  of  an  infinite  cpo,  consider  the  set  N  of  natural  numbers  with  the  discrete  ordering 
( i.e .  n  Q  m  if  and  only  if  n  =  m).  To  get  a  cpo,  we  need  to  add  a  “bottom”  element  to  N.  The 
result  is  a  cpo  Nx  which  is  pictured  in  Figure  1.1.  This  is  a  rather  simple  example  because  it  does 
not  have  any  interesting  directed  subsets.  Consider  the  ordinal  u;  it  is  not  a  cpo  because  it  has 
a  directed  subset  (namely  u>  itself)  which  has  no  least  upper  bound.  To  get  a  cpo,  one  needs  to 
add  a  top  element  to  get  the  cpo  wT  pictured  in  Figure  1.1.  For  a  more  subtle  class  of  examples 
of  cpo’s,  let  VS  be  the  set  of  (all)  subsets  of  a  set  S.  Ordered  by  ordinary  set  inclusion.  VS  forms 
a  cpo  whose  least  upper  bound  operation  is  just  set  inclusion.  As  a  last  example,  consider  the  set 
Q  of  rational  numbers  with  their  usual  ordering.  Of  course,  Q  lacks  the  bottom  and  top  elements, 
but  there  is  another  problem  which  causes  Q  to  fail  to  be  a  cpo:  Q  lacks,  for  example,  the  square 
root  of  2!  However,  the  unit  interval  [0, 1]  of  real  numbers  does  form  a  cpo. 

Given  cpo’s  D  and  E,  a  function  /  :  D  — *  E  is  monotone  if  /(x)  C  f(y)  whenever  x  C  y.  If 
/  is  monotone  and  /((JAf)  =  (J  f(M)  for  every  directed  M,  then  /  is  said  to  be  continuous.  A 
function  /  :  D  — *  E  is  said  to  be  strict  if  /( _L)  =  _L.  We  will  usually  write  f  :  D  o —  E  to  indicate 
that  /  is  strict.  If  f,g  :  D  — ♦  E,  then  we  say  that  /  C  g  if  and  only  if  /(x)  Cj(x)  for  every  x  £  D. 
With  this  ordering,  the  poset  of  continuous  functions  D  —>  E  is  itself  a  cpo.  Similarly,  the  poset 
of  strict  continuous  functions  D  o— ►  E  is  also  a  cpo.  (Warning:  we  use  the  notation  /  :  D  —  E  to 
indicate  that  /  is  a  function  with  domain  D  and  codomain  E  in  the  usual  set-theoretic  sense.  On 
the  other  hand,  /  £  D  — *  E  means  that  /  :  D  -*  E  is  continuous.  A  similar  convention  applies  to 
D  o — »  E . ) 

To  get  a  few  examples  of  continuous  functions,  note  that  when  /  :  D  -*  E  is  monotone  and  D 
is  finite,  then  /  is  continuous.  In  fact,  this  is  true  whenever  D  has  no  infinite  ascending  chains. 
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Figure  1.1:  Examples  of  cpo’s. 

For  example,  any  monotone  function  /  :  Nx  — 1 ►  E  is  continuous.  On  the  other  hand,  the  function 
f  :uT  -*  0  which  sends  the  elements  of  u  to  X  and  sends  T  to  T  is  monotone,  but  it  is  not 
continuous.  Given  sets  S,  T  and  function  f  :  S  T  we  define  the  extension  of  /  to  be  the  function 
/*  :  VS  -*■  VT  given  by  taking 

f(X)  =  {/(*)  |  X  €  X} 

for  each  subset  X  C  S.  The  function  /*  is  monotone  and,  for  any  collection  Xt  of  subsets  of  S.  we 
have 

r(U*«)  =  U /*(*«)• 

i  t 

In  particular,  /*  is  continuous.  For  readers  who  know  a  bit  about  functions  on  the  real  numbers, 
it  is  worth  noting  that  a  function  /  :  [0, 1]  — *  [0, 1]  on  the  unit  interval  may  be  continuous  in  the 
cpo  sense  without  being  continuous  in  the  usual  sense. 

Now,  the  central  theorem  may  be  stated  as  follows: 

Theorem  1  (Fixed  Point)  If  D  is  a  cpo  and  f  :  D  —*  D  is  continuous,  then  there  is  a  point 
fix( /)  g  D  such  that  fix(/)  =  /(fix(/))  and  fix(/)  C  x  for  any  x  €  D  such  that  x  =  f{x).  In  other 
words,  fix(/)  is  the  least  fixed  point  of  f . 

Proof:  Note  that  X  C  /(X).  By  an  induction  on  n  using  the  monotonicity  of  /,  it  is  easy  to  see 
that  /n(X)  C  /n+1(X)  for  every  n.  Set  fix(/)  =  [_!„  /”(!)•  By  the  continuity  of  /.  it  is  easy  to  see 
that  fix(/)  is  a  fixed  point  of  /.  To  see  that  it  is  the  least  such,  note  that  if  <  fixed  point  of  /, 
then,  for  each  n,  /n(X)  C  fn(x )  =  x.  | 
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1.2.2  Some  applications  of  the  Fixed  Point  Theorem. 


The  factorial  function.  As  a  first  illustration  of  the  use  of  the  Fixed  Point  Theorem,  let  us  consider 
how  one  might  define  the  factorial  function  fact  :  Nj_  — ►  N  j_.  The  usual  approach  is  to  say  that 
the  factorial  function  is  a  strict  function  which  satisfies  the  following  recursive  equation  for  each 
number  n: 


fact(n)  = 


{ 


1 

n  *  fact(n  —  1) 


if  n  =  0 
if  n  >  0. 


where  *,-:NxN-*N  are  multiplication  and  subtraction  respectively.  But  how  do  we  know  that 
there  is  a  function  fact  which  satisfies  this  equation?  Define  a  function 


F  :  ( N j_  0-+  Nx)  — »  (Nj.  o->  Nx) 


by  setting: 


WX») 


1  if  n  =  0 

<  n  *  f(n  —  1)  if  n  >  0 
J.  if  n  =  ± 


for  each  /  :  Nx  <>-*■  Nx-  The  definition  of  F  is  not  recursive  (F  appears  only  on  the  left  side  of  the 
equation)  so  F  certainly  exists.  Moreover,  it  is  easy  to  check  that  F  is  continuous  (but  not  strict). 
Hence,  by  the  Fixed  Point  Theorem,  F  has  a  least  fixed  point  fix(F)  and  this  solution  will  satisfy 
the  equation  for  fact. 


Context  Free  Grammars.  One  familiar  kind  of  recursion  equation  is  a  context  free  grammar.  Let 
£  be  an  alphabet.  One  uses  context  free  grammars  to  specify  subsets  of  the  collection  £*  of  finite 
sequences  of  letters  from  S.1  Here  are  some  easy  examples: 


1. 

E  ::=  e  |  Ea 

defines  the  strings  of  a’s  (including  the  empty  string  e). 

2. 

E  ::=  a  |  bEb 

defines  strings  consisting  either  of  the  letter  a  alone  or  a  string  of  n  b's  followed  by  an  a 
followed  by  n  more  6’s. 


3. 


E  ::=  e  |  aa  |  EE 


defines  strings  of  a’s  of  even  length. 

‘The  superscripted  asterisk  will  be  used  in  three  entirely  different  ways  in  this  chapter.  Unfortunately,  all  of  these 
usages  are  standard.  Fortunately,  however,  it  is  usually  easy  to  tell  which  meaning  is  correct  from  context. 
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We  may  use  the  Fixed  Point  Theorem  to  provide  a  precise  explanation  of  the  semantics  of  these 
grammars.  Since  the  operations  X  >-*  {(}UT{o},  X  {a}U{6}X{6},  and  X  {c}u{a}{a}U.Y.Y 
are  all  continuous  in  the  variable  X,  it  follows  from  the  Fixed  Point  Theorem  that  equations  such 
as 


1.  X  =  {e}uX{a} 

2.  X  =  {a}  U  {b}X{b} 

3.  X  =  {e}  U  {a}{a}  U  XX 

corresponding  to  the  three  grammars  mentioned  above  all  have  least  solutions.  These  solutions  are 
the  languages  defined  by  the  grammars. 

The  Schroder- Bernstein  Theorem .  As  a  set-theoretic  application  of  the  Fixed  Point  Theorem  we 
offer  the  proof  of  the  following: 

Theorem  2  (Schroder- Bernstein)  Let  S  and  T  be  sets.  If  f  :  S  — *•  T  and  g  :T  — <•  S  are  injec¬ 
tions,  then  there  is  a  bijection  h  :  S  — *•  T. 

Proof:  The  function  Y  *-*  {T  -  /*(S))  U  f*(gm(Y))  from  VT  to  VT  is  easily  seen  to  be  continuous 
with  respect  to  the  inclusion  ordering.  Hence,  by  the  Fixed  Point  Theorem,  there  is  a  subset 

y  =  (T-/*(5))urm 


In  particular,  T  -Y  =  f*(S  -  <7*(Y))  since 

T-Y  =  T  —  ((T  —  U  f“{gm(Y))) 

=  (T-(T-r(5)))n(T-(/*(5*(y)))) 

=  f’{S)n(T  -  {/’{g‘(Y)))) 

=  r(S-g-(Y)) 

Now  define  h  :  S  —*  T  by 

_  /  V  if  x  =  g(y)  for  some  y  6  Y 
\  f(x)  otherwise 

This  makes  sense  because  g  is  an  injection.  Moreover,  h  itself  is  an  injection  since  /  and  g  are 
injections.  To  see  that  it  is  a  surjection,  suppose  y  £  T.  If  y  G  Y,  then  h(g(y))  =  y.  If  y  £  Y ,  then 
y  €  f“(S  —  <7*(F)),  so  y  =  f(x)  =  h(x)  for  some  x.  Thus  h  is  a  bijection.  | 


1.2.3  Uniformity. 

The  question  naturally  arises  a s  to  why  we  take  the  least  fixed  point  in  order  to  get  the  meaning.  In 
most  instances  there  will  be  other  choices.  There  are  several  answers  to  this  question.  First  of  ail.  it 
seems  intuitively  reasonable  to  take  the  least  defined  function  satisfying  a  given  recursive  equation. 
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But  more  importantly,  taking  the  least  fixed  point  yields  a  canonical  solution.  Indeed,  it  is  possible 
to  show  that,  given  a  cpo  D,  the  function  fix#  :  (D  —*  D)  — ►  D  given  by  fix£>(/)  =  m  /n(J_)  is 
actually  continuous.  But  are  there  other  operators  like  fix  that  could  be  used?  A  definition  is 
helpful: 

Definition:  A  fixed  point  operator  F  is  a  class  of  continuous  functions 

Fd  :  (D  —*■  D)  -+  D 

such  that,  for  each  cpo  D  and  continuous  function  f  :  D  —*  D,  we  have  Fo(f)  =  /( Fo(f ))■  I 

Let  us  say  that  a  fixed  point  operator  F  is  uniform  if,  for  any  pair  of  continuous  functions 
/  :  D  — »  D  and  g  :  E  —*■  E  and  strict  continuous  function  h  :  D  o-+  E  which  makes  the  following 
diagram  commute 


we  have  h(Fo(f))  =  Fs(g ).  We  leave  it  to  the  reader  to  show  that  fix  is  a  uniform  fixed  point 
operator.  What  is  less  obvious,  and  somewhat  more  surprising,  is  the  following: 

Theorem  3  fix  is  the  unique  uniform  fixed  point  operator. 

Proof:  To  see  why  this  must  be  the  case,  let  D  be  a  cpo  and  suppose  /  :  D  —  D  is  continuous. 
Then  the  set 

D'={xeD\xC  fix(/)} 

is  a  cpo  under  the  order  that  it  inherits  from  the  order  on  D.  In  particular,  the  restriction  f  of 
/  to  D'  has  fix£»(/)  as  its  unique  fixed  point.  Now,  if  i  D'  -*  D  is  the  inclusion  map  then  the 
following  diagram  commutes 


i 


Thus,  if  F  is  a  uniform  fixed  point  operator,  we  must  have  Fo(f)  =  FD,(f).  But  FD>{f)  is  a  fixed 
point  of  f  and  must  therefore  be  equal  to  fix£?(/).  | 

We  hope  that  these  results  go  some  distance  toward  convincing  the  reader  that  fix  is  a  reasonable 
operator  to  use  for  the  semantics  of  recursively  defined  functions. 
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1.3  Effectively  presented  domains. 


There  is  a  significant  problem  with  the  full  class  cf  cpo’s  as  far  as  the  theory  of  computation  goes. 
There  does  not  seem  to  be  any  reasonable  way  to  define  a  general  notion  of  computable  function 
between  cpo’s.  It  is  easy  to  see  that  these  ideas  make  perfectly  good  sense  for  a  noteworthy 
collection  of  examples.  Consider  a  strict  function  /  :  Nx  ©-»•  Nj..  If  we  take  f(n)  =  ±  to  mean  that 
/  is  undefined  at  n,  then  /  can  be  viewed  as  a  partial  function  on  N.  We  wish  to  have  a  concept 
of  computability  for  functions  on  (some  class  of)  cpo’s  so  that  /  is  computable  just  in  case  it 
corresponds  to  the  usual  notion  of  a  partial  recursive  function.  But  we  must  also  have  a  definition 
that  applies  to  functionals,  that  is,  functions  which  may  take  functions  as  arguments  or  return 
functions  as  values.  We  already  encountered  a  functional  earlier  when  we  defined  the  factorial.  To 
illustrate  the  point  that  there  is  a  concept  of  computability  that  applies  to  such  operators,  consider, 
for  example,  a  functional  F  :  (Nx  o-»  Nx)  o— ►  Nx  which  takes  a  function  /  :  Nx  <>-*■  Nx  and  computes 
the  value  of  /  on  the  number  3.  The  functional  F  is  continuous  and  it  is  intuitively  computable. 
This  intuition  comes  from  the  fact  that,  to  compute  F(f)  on  an  argument  one  needs  only  know 
how  to  compute  /  on  an  argument. 

Our  goal  is  to  define  a  class  of  cpo’s  for  which  a  notion  of  “finite  approximation”  makes  sense. 
Let  D  be  a  cpo.  An  element  x  G  D  is  compact  if,  whenever  M  is  a  directed  subset  of  D  and 
x  C  LJAf,  there  is  a  point  y  €  M  such  that  iCj.  We  let  K{D )  denote  the  set  of  compact  elements 
of  D.  The  cpo  D  is  said  to  be  algebraic  if,  for  every  x  6  D,  the  set  M  =  {x0  €  K{D)  \  x0  C  x}  is 
directed  and  (JA/  =  x.  In  other  words,  in  an  algebraic  cpo,  each  element  is  a  directed  limit  of  its 
“finite”  (compact)  approximations.  If  D  is  algebraic  and  K(D)  is  countable,  then  we  will  say  that 
D  is  a  domain. 

With  the  exception  of  the  unit  interval  of  real  numbers,  all  of  the  cpo’s  we  have  mentioned  so  far 
are  domains.  The  compact  elements  of  the  domain  Nx  Nx  are  the  functions  with  finite  domain 
of  definition,  i.e.  those  continuous  functions  /  :  Nx°->  Nx  such  that  {n  |  f(n)  1}  is  finite.  As 
another  example,  the  collection  Vfi  of  subsets  of  N,  ordered  by  subset  inclusion  is  a  domain  whose 
compact  elements  are  just  the  finite  subsets  of  N. 

One  thing  which  makes  domains  particularly  nice  to  work  with  is  the  way  one  may  describe  a 
continuous  function  f  :  D  -*  E  between  domains  D  and  E  using  the  compact  elements.  Let  Gf  be 
the  set  of  pairs  (x0,j/o)  such  that  x0  €  K{D)  and  y0  6  K{E)  and  y0  C  /(x0).  If  x  6  D,  then  one 
may  recover  from  G /  the  value  of  /  on  x  as 

/(*)  =  LKyo  |  (xa,ya)  6  Gs  and  x0  C  x}. 

This  allows  us  to  characterize,  for  example,  a  continuous  function  f  :V  N  —  T^N  between  uncount¬ 
able  cpo’s  with  a  countable  set  Gf.  The  significance  of  this  fact  for  the  theory  of  computability  is 
not  hard  to  see;  we  will  say  that  the  function  /  is  computable  just  in  case  Gf  is  computable  (in  a 
sense  to  be  made  precise  below). 
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1.3.1  Normal  subposets  and  projections. 

Before  we  give  the  formal  definition  of  computability  for  domains  and  continuous  functions,  we 
digress  briefly  to  introduce  a  useful  relation  on  subposets.  Given  a  poset  (A,C)  and  x  £  A,  let 
lx  =  {y  £  A  |  y  C  x}. 

Definition:  Let  A  be  a  poset  and  suppose  N  C  A.  Then  N  is  said  to  be  normal  in  A  (and  we 
write  N  <  A)  if,  for  every  x  £  A,  the  set  N  n  j  x  is  directed.  | 

The  following  lemma  lists  some  useful  properties  of  the  relation  c. 

Lemma  4  Let  C  be  a  poset  with  a  least  element  and  suppose  A  and  B  are  subsets  of  C. 

1.  IfA<B<C  thenA<C. 

2.  If  AC  B  C  C  and  A<C  then  A<  B. 

3.  If  A  <C,  then  X  6  A. 

4 ■  (V(C),<)  is  a  cpo  with  {X}  as  its  least  element.  | 

Intuitively,  a  normal  subposet  N<  A  is  an  “approximation”  to  A.  The  notion  of  normal  subposet 
is  closely  related  to  one  of  the  central  concepts  in  the  theory  of  domains.  A  pair  of  continuous 
functions  g  :  D  — »  E  and  /  :  E  -*  D  is  said  to  be  am  embedding-projection  pair  ( g  is  the  embedding 
and  /  is  the  projection)  if  they  satisfy  the  following 

fo  g  =  id/? 
go  f  C  \6e 

where  id#  and  id#  are  the  identity  functions  on  D  and  E  respectively  (in  future,  we  drop  the 
subscripts  when  D  and  E  are  clear  from  context)  and  composition  of  functions  is  defined  by 
(/  0  9)(x)  —  /(<7(x)).  One  cam  show  that  each  of  /  and  g  uniquely  determines  the  other.  Hence 
it  makes  sense  to  refer  to  /  as  the  projection  determined  by  g  and  refer  to  g  as  the  embedding 
determined  by  f.  There  is  quite  a  lot  to  be  said  about  properties  of  projections  and  embeddings 
and  we  cannot  begin  to  provide,  in  the  space  of  this  chapter,  the  full  discussion  that  these  concepts 
deserve  (the  reader  may  consult  Chapter  0  of  [GHK*80]  for  this).  However,  a  few  observations  will 
be  essential  to  what  follows.  We  first  provide  a  simple  example: 


Example:  If  /  :  D  — ►  E  is  a  continuous  function  then  there  is  a  strict  continuous  function 
strict  :  (D  —  E)  — ►  (D  o— ♦  E)  given  by: 


strict(/)(x) 


f  /(*)  if  x  jt  X 
\  X  if  x  =  X 


The  function  strict  is  a  projection  whose  corresponding  embedding  is  the  inclusion  map  incl  : 
(D^E)^{D  -  E).  | 
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In  our  discussion  below  we  will  not  try  to  make  much  of  the  distinction  between  /  :  D  o— ►  E 
and  inci(/)  :  D  — ►  E  (for  example,  we  may  write  id  :  D  o— ►  D  as  well  as  id  :  D  — *•  D  or  even 
ind(id)  :  D  — *  D).  From  the  two  equations  that  define  the  relationship  between  a  projection  and 
embedding,  it  is  easy  to  see  that  a  projection  is  a  surjection  ( i.e .  onto)  and  an  embedding  is  an 
injection  (i.e.  one-to-one).  Thus  one  may  well  think  of  the  image  of  an  embedding  g  :  D  — «•  E  as  a 
special  kind  of  sub-cpo  of  E.  We  shall  be  especially  interested  in  the  case  where  an  embedding  is  an 
inclusion  as  in  the  case  of  Do-*  E  and  D  — *•  E.  Let  D  be  a  cpo.  We  say  that  a  continuous  function 
p  :  D  — *  D  is  a  finitary  projection  if  pop  =  p  C  id  and  im(p)  =  {p(x)  |  x  G  D}  is  a  domain.  Note,  in 
particular,  that  the  inclusion  map  from  im(p)  into  D  is  an  embedding  (which  has  the  corestriction 
of  p  to  its  image  as  the  corresponding  projection).  It  is  possible  to  characterize  the  basis  of  im(p) 
as  follows: 

Lemma  5  If  D  is  a  domain  andp  :  D  — *■  D  is  a  finitary  projection ,  then  the  set  of  compact  elements 
of  im(p)  is  just  im(p)  n  K(D).  Moreover,  im(p)  fl  K(D )  <  K(D).  | 

Suppose,  on  the  other  hand,  that  N  <K(D).  Then  it  is  easy  to  check  that  the  function  pn  :  D  —>  D 
given  by 

pn(x)  =  LKy  e  N  I  y  Q  *} 

is  a  finitary  projection.  Indeed,  the  correspondence  N  >-+  ph  is  inverse  to  the  correspondence 
p  *-*  im(p)  n  K(D)  and  we  have  the  following: 

Theorem  Q  For  any  domain  D  there  is  an  isomorphism  between  the  cpo  of  normal  substructures 
of  K(D)  and  the  poset  Fp  (D)  of  finitary  projections  on  D.  | 

In  particular,  if  M  C  Fp (D)  is  directed  then  im([JA/)  is  a  domain.  This  is  a  fact  which  will  be 
significant  later.  Indeed,  the  notions  of  projection  and  normal  subposet  will  come  up  again  and 
again  throughout  the  rest  of  our  discussion. 

1.3.2  Effectively  presented  domains. 

Returning  now  to  the  topic  of  computability,  we  will  say  that  a  domain  is  effectively  presented  if 
the  ordering  on  its  basis  is  decidable  and  it  is  possible  to  effectively  recognize  the  finite  normal 
subposets  of  the  basis: 

Definition:  Let  D  be  a  domain  and  suppose  d  :  N  — ►  K(D)  is  a  surjection.  Then  d  is  an  effective 
presentation  of  D  if 

1.  the  set  {(m,n)  |  dm  C  dn }  is  effectively  decidable,  and 

2.  for  any  finite  set  u  C  N,  it  is  decidable  whether  {dn  |  n  6  u}  <  K(D). 

If  (D,d)  and  (E,e)  are  effectively  presented  domains,  then  a  continuous  function  /  :  D  —  E  is  said 
to  be  computable  (with  respect  co  d  and  e)  if  and  only  if,  for  every  n  €  N,  the  sot  fm  j  em  C  f(dn )} 
is  recursively  enumerable.  | 
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Unfortunately,  the  full  class  of  domains  has  a  serious  problem.  It  is  this:  there  are  domains  D ,  E 
such  that  the  cpo  D  -*  E  is  not  a  domain  (we  will  return  to  this  topic  in  Section  1.6).  Since  we 
wish  to  use  D  — ►  E  in  defining  computability  at  higher  types,  we  need  some  restriction  on  domains 
D  and  E  which  will  insure  that  D  — *  E  is  a  domain.  There  are  several  restrictions  which  will  work. 
We  begin  by  presenting  one  which  is  relatively  simple.  Another  will  be  discussed  later. 

Definition:  A  poset  A  is  said  to  be  bounded  complete  if  A  has  a  least  element  and  every  bounded 
subset  of  A  has  a  least  upper  bound.  | 

The  bounded  complete  domains  are  closely  related  to  a  more  familiar  class  of  cpo’s  which  arise 
in  many  places  in  classical  mathematics.  A  domain  D  is  a  (countably  based)  algebraic  lattice  if  every 
subset  of  D  has  a  least  upper  bound.  It  is  not  hard  to  see  that  a  domain  D  is  bounded  complete  if 
and  only  if  the  cpo  Dr  which  results  from  adding  a  new  top  element  to  D  is  an  algebraic  lattice. 
The  poset  PN  is  an  example  of  an  algebraic  lattice.  On  the  other  hand,  the  bounded  complete 
domain  Nxo-*  Nx  lacks  a  top  element  and  therefore  fails  to  be  an  algebraic  lattice.  All  of  the 
domains  we  have  discussed  so  far  are  bounded  complete.  In  particular,  we  have  the  following: 

Theorem  7  If  D  and  E  are  bounded  complete  domains,  then  D  —*  E  is  also  a  bounded  complete 
domain.  Moreover,  if  D  and  E  have  effective  presentations,  then  D  — *  E  has  an  effective  presen¬ 
tation  as  well.  Similar  facts  hold  for  Do-*  E. 

Proof:  (Sketch)  It  is  not  hard  to  see  that  D  E  is  a  bounded  complete  cpo  whenever  E  is. 
To  prove  that  D  — *•  E  is  a  domain  we  must  demonstrate  its  basis.  Suppose  N  <  K(D)  is  finite 
and  s  :  N  — *  K(E)  is  monotone.  Then  the  function  step(s) :  D  —  F  given  by  taking  step(s)(x)  = 
LK/(y)  I  V  €  N  n  1  x}  is  continuous  and  compact  in  the  ordering  on  D  — •  E.  These  are  called  step 
functions  and  it  is  possible  to  show  that  they  form  a  basis  for  D  — *•  E.  The  proof  that  the  poset 
of  step  functions  has  decidable  ordering  and  finite  normal  subposets  is  tedious,  but  not  difficult, 
using  the  effective  presentations  of  D  and  E.  The  proof  of  these  facts  for  D  o— ■  E  is  essentially  the 
same  since  the  strict  step  functions  form  a  basis.  | 

In  the  remaining  sections  of  the  chapter  we  will  discuss  a  great  many  operators  like  •  —  •  and 
••  We  will  leave  it  to  the  reader  to  convince  himself  that  all  of  these  operators  preserve  the 
property  of  having  an  effective  presentation.  Further  discussion  of  computability  on  domains  may 
be  found  in  [Smy77]  and  [KT84].  It  is  hoped  that  future  research  in  the  theory  of  domains  will 
provide  a  general  technique  which  will  incorporate  computability  into  the  logic  whereby  we  reason 
about  the  existence  of  our  operators.  This  will  eliminate  the  need  to  provide  demonstrations  of 
effective  presentations.  This  is  a  central  idea  in  current  investigations  but  it  is  beyond  our  scope 
to  discuss  it  further. 
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1.4  Operators  and  functions. 

There  are  a  host  of  operators  on  domains  which  are  needed  for  the  purposes  of  semantic  definitions. 
In  this  section  we  mention  a  few  of  them.  An  essential  technique  for  building  new  operators 
from  those  which  we  present  here  will  be  introduced  below  when  we  discuss  solutions  of  recursive 
equations. 

1.4.1  Products. 

Given  posets  D  and  E,  the  product  D  x  E  is  the  set  of  pairs  (x,y),  where  x  6  D  and  y  £  E. 
The  ordering  is  coordinatewise,  i.e.  ( x,y )  C  ( x \y')  if  and  only  if  x  C  x'  and  y  C  y'.  We  define 
functions  fst  :  D  x  E  — *  D  and  snd  :  D  x  E  — *  E  given  by  fst(x,y)  =  x  and  snd(x,  y)  =  y.  If  a 
subset  L  C  D  x  E  is  directed,  then 

M  =  fst*(Z)  =  {x\3y&E.  (x,y)  6  L} 

N  =  snd*(Z)  =  {y  |  3x  €  D.  (x,y)  €  Z} 

are  directed.  In  particular,  if  D  and  E  are  cpo’s,  then  |JZ  =  {\JM,  |JjV)  and,  of  course,  ±d*e  = 
(±£>,  ±e),  so  D  x  E  is  a  cpo.  Indeed,  if  D  and  E  are  domains,  then  D  x  E  is  also  a  domain  with 
K(D  x  E)  =  K(D)  x  K(E).  The  property  of  bounded  completeness  is  also  preserved  by  x. 

Given  epos  D,  E,  F,  one  can  show  that  a  function  /  :  D  x  E  — ►  F  is  continuous  if  and  only  if  it 
is  continuous  in  each  of  its  arguments  individually.  In  other  words,  /  is  continuous  iff  each  of  the 
following  conditions  holds: 

1.  For  every  directed  set  M  C  D  and  element  e  6  £,  the  function  f\-.D-*F  given  by  x  — 
/(x,e)  is  continuous. 

2.  For  every  directed  set  N  C  E  and  element  d  6  D,  the  function  f^’-E—^F  given  by  y  >— 
f(d,y)  is  continuous. 

We  leave  the  proof  of  this  equivalence  as  an  exercise  for  the  reader. 

It  is  easy  to  see  that  each  of  the  functions  fst  and  snd  is  continuous.  Moreover,  given 
any  cpo  F  and  continuous  functions  /  :  F  — ►  D  and  g  :  F  — *■  E,  there  is  a  continuous  function 
(f,g)  :  F  —*  D  x  E  such  that 

0  (/,  9)  =  / 
snd  o  (f,g)  =  g 

and,  for  any  continuous  function  h  :  F  — »  D  x  E, 

(fst  o  h,snd  o  h)  =  h. 

The  function  (f,g)  is  given  by  < f,g)(x )  =  (f(x),g(x)). 

There  is  another,  more  pictorial,  way  of  stating  these  equational  properties  of  the  operator 
{•>  •)  using  a  commutative  diagram.  The  desired  property  can  be  stated  in  the  following  manner: 
given  any  cpo  F  and  continuous  functions  /  :  F  —  D  and  g  :  F  —  E,  there  is  a  unique  continuous 
function  {/,  g)  which  completes  the  following  diagram: 
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D 


snd 

E 

This  is  referred  to  as  the  universal  property  of  the  operator  x.  As  operators  are  given  below  we 
will  describe  the  universal  properties  that  they  satisfy  and  these  will  form  the  basis  of  a  system  of 
equations!  reasoning  about  continuous  functions.  Virtually  all  of  the  functions  needed  to  describe 
the  semantics  of  (a  wide  variety  of)  programming  languages  may  be  built  from  those  which  are 
used  in  expressing  these  universal  properties! 

Given  continuous  functions  /  :  D  — *  D'  and  g  :  E  —*  E',  we  may  define  a  continuous  function 
/  x  g  which  takes  ( x,y )  to  (f(x),g(y))  by  setting 

/  x  9  —  (f  °  fst,^o  snd)  :  D  x  E  — <•  D'  x  E’. 

It  is  easy  to  show  that  ido  x  id#  =  id£>X£  and 

(/  X  g)  o  (/'  x  g')  =  (/  o  /')  x  {g  o  g'). 

Note  that  we  have  “overloaded”  the  symbol  X  so  that  it  works  both  on  pairs  of  domains  and  pairs  of 
functions.  This  sort  of  overloading  is  quite  common  in  mathematics  and  we  will  use  it  often  below. 
In  this  case  (and  others  to  follow)  we  have  an  example  of  what  mathematicians  call  a  functor. 

There  is  a  very  important  relationship  between  the  operators  — «  and  x.  Let  D.  E  and  F  be 
cpo’s.  Then  there  is  a  function 

apply  :  (( E  -*  F)  x  E)  —>  F 

given  by  taking  apply(/,x)  to  be  f{x)  for  any  function  /  :  E  -*  F  and  element  x  e  E.  Indeed,  the 
function  apply  is  continuous.  Also,  given  a  function  /  :  D  x  E  — ■  F,  there  is  a  continuous  function 

curryf/)  :  D  -  (E  -  F) 

given  by  taking  curry(/)(x)(y)  to  be  f(x,y).  Moreover,  curry(/)  is  the  unique  continuous  function 
which  makes  the  following  diagram  commute: 

/ 

D  x  E  - ►  F 

i 
i 

curry(/)  x  id  \ 

i 
i 

1 

{E  —>  F)  x  E 
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This  uniqueness  condition  is  equivalent  to  the  following  equation: 

curry(apply  o  (h  x  id^))  =  h  (1-1) 

To  see  this,  suppose  equation  (1.1)  holds  and  h  satisfies 
/  =  apply  o  (fix  id) 

then 

curry(/)  =  curry(apply  o  (h  X  id))  =  h 

so  the  uniqueness  condition  is  satisfied.  On  the  other  hand,  if  curry(/)  is  uniquely  determined  by  the 
diagram  above,  then  equation  (1.1)  follows  immediately  from  the  commutativity  of  the  following 
diagram: 


/ 

D  x  E  - -  F 


for  /  =  apply  o  (h  x  id#). 

It  is  often  useful  to  have  a  multiary  notation  for  products.  We  write 

x()  =  l 

x ( D\ , . . . , Dn )  =  x(£>x,...,Z?„_ x)  x  Dn 

and  define  projections 

on,  :  x(Z?i,. . .  ,Dn)  —  D, 
by 

on,  =  snd  o  fstn-< 

Similarly,  one  defines  a  multiary  version  of  the  pairing  operation  by  taking  ( )  to  be  the  identity  on 
the  one  point  domain  and  defining 

(fl . /«>  =  ((/!,. 


These  multiary  versions  of  projection  and  pairing  satisfy  a  universal  property  similar  to  the  one  for 
the  binary  product. 


1.4.2  Church’s  A-notation. 

If  we  wish  to  define  a  function  from,  say,  natural  numbers  to  natural  numbers,  we  typically  do 
so  by  describing  the  action  of  that  function  on  a  generic  number  x  (a  variable)  using  previously 
defined  functions.  For  example,  the  squaring  function  /  has  the  action  x  x  *  x  where  *  is  the 
multiplication  function.  We  may  now  use  /  to  define  other  functions:  for  example,  a  function  g 
which  takes  a  function  h  :  N  — ►  N  to  /  o  h.  Continuing  in  this  way  we  may  construct  increasingly 
complex  function  definitions.  However,  it  is  sometimes  useful  to  have  a  notation  for  functions  which 
alleviates  the  necessity  of  introducing  intermediate  names.  This  purpose  is  served  by  a  terminology 
known  as  A-notation  which  is  originally  due  to  Church. 

The  idea  is  this.  Instead  of  introducing  a  term  such  as  /  and  describing  its  action  as  a  function, 
one  simply  gives  the  function  a  name  which  is  basically  a  description  of  what  it  does  with  its 
argument.  In  the  above  case  one  writes  Ax.  x  *  x  for  /  and  A h.  f  o  h  for  g.  One  can  use  this 
notation  to  define  g  without  introducing  /  by  defining  g  to  be  the  function  A h.  (Ax.  x  *  x)o  h.  The 
A/i  at  the  beginning  of  this  expression  says  that  g  is  a  function  which  is  computed  by  taking  its 
argument  and  substituting  it  for  the  variable  h  in  the  expression  (Ax.  x  *  x)  o  h. 

The  use  of  the  Greek  letter  A  for  the  operator  which  binds  variables  is  primarily  an  historical  ac¬ 
cident.  Various  programming  languages  incorporate  something  essentially  equivalent  to  A-notation 
using  other  names.  In  mathematics  textbooks  it  is  common  to  avoid  the  use  of  such  notation  by 
assuming  conventions  about  variable  names.  For  example,  one  may  write 

x2  -  2  *  x 

for  the  function  which  takes  a  real  number  as  an  argument  and  produces  as  result  the  square  of 
that  number  less  its  double.  An  expression  such  as 

x2  +  x  *  y  +  y2 

would  denote  a  function  which  takes  two  numbers  as  arguments — that  is,  the  values  of  x  and  y — 
and  produces  the  square  of  the  one  number  plus  the  square  of  the  other  plus  the  product  of  the 
two.  One  might  therefore  provide  a  name  for  this  function  by  writing  something  like: 

f(x,y)  =  x2  +  x*y  +  y2. 

So  /  is  a  function  which  takes  a  pair  of  numbers  and  produces  a  number.  But  what  notation 
should  we  use  for  the  function  g  that  takes  a  number  n  as  argument  and  produces  the  function 
n>—  x2  +  x  «  n  4-  n2?  For  example,  g(  2)  is  the  function  x2  +  2  *  x  +  4.  It  is  not  hard  to  see  that  this 
is  closely  related  to  the  function  curry  which  we  discussed  above.  Modulo  the  fact  that  we  defined 
curry  for  domains  above,  we  might  have  written  g  =  curry(/).  Or,  to  define  g  directly,  we  would 
write 

g  =  Ay.  Ax.  x2  +  x  *  y  +  y2. 

The  definition  of  /  would  need  to  be  given  differently  since  /  takes  a  pair  as  an  argument.  We 
therefore  write: 

/  =  A(x,  y).  x2  +  x  *  y  +  y2 . 
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There  is  no  impediment  to  using  this  notation  to  describe  higher-order  functions  as  well.  For 
example, 

A/.  /(3) 

takes  a  function  /  and  evaluates  it  on  the  number  3  and 

Xf.fof 

takes  a  function  and  composes  it  with  itself.  But  these  definitions  highlight  a  very  critical  issue. 
Note  that  both  definitions  are  ambiguous  as  they  stand.  Does  the  function  A/.  /( 3)  take,  for 
example,  functions  from  numbers  to  reals  as  argument  or  does  it  take  a  function  from  numbers  to 
sets  of  numbers  as  argument?  Either  of  these  would,  by  itself,  make  sense.  What  we  need  to  do 
is  indicate  somewhere  in  the  expression  the  types  of  the  variables  (and  constants  if  their  types  are 
not  already  understood).  So  we  might  write 

A/  :  N  — ►  R.  /(3) 

for  the  operator  taking  a  real  valued  function  as  argument  and 

A/  :  N  -  7>N.  /(3) 

for  the  operator  taking  a  PN  valued  function. 

So  far,  what  we  have  said  applies  to  almost  any  class  of  spaces  and  functions  where  products 
and  an  operator  like  curry  are  defined.  But  for  the  purposes  of  programming  semantics,  we  need  a 
semantic  theory  that  includes  the  concept  of  a  fixed  point.  Such  fixed  points  are  guaranteed  if  we 
stay  within  the  realm  of  cpo’s  and  continuous  functions.  But  the  crucial  fact  is  this:  the  process  of 
X- abstraction  preserves  continuity.  This  is  because  curry(/)  is  continuous  whenever  /  is.  We  may 
therefore  use  the  notational  tools  we  have  described  above  with  complete  freedom  and  still  be  sure 
that  recursive  definitions  using  this  notation  make  sense. 

Demonstrating  that  the  typed  A-calculus  ( i.e .  the  system  of  notations  that  we  have  been  de¬ 
scribing  informally  here)  is  really  useful  in  explaining  the  semantics  of  programming  languages  is 
not  the  objective  of  this  chapter.  However,  one  can  already  see  that  it  provides  a  considerable 
latitude  for  writing  function  definitions  in  a  simple  and  mathematically  perspicuous  manner. 

1.4.3  Smash  products. 

In  the  product  D  x  E  of  cpo’s  D  and  E,  there  are  elements  of  the  form  (x,  _L)  and  (±,y).  If  x  ^  1 
or  y  ^  -L,  then  these  will  be  distinct  members  of  D  x  E.  In  programming  semantics,  there  are 
occasions  when  it  is  desirable  to  identify  the  pairs  (x,  J.)  and  (_L,y).  For  this  purpose,  there  is  a 
collapsed  version  of  the  product  called  the  smash  product.  For  cpo’s  D  and  £,  the  smash  product 
D  9)  F  ' s  the  set 

{(x, y)  6  D  x  E  |  x  ^  1  and  y  /  1}  U  {±d®e} 
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where  -Ld®£  is  some  new  element  which  is  not  a  pair.  The  ordering  on  pairs  is  coordinatewise  and 
we  stipulate  that  ±d®E  Q  z  for  every  z  €  D  0  E.  There  is  a  continuous  surjection 

smash  :  D  X  E  — *■  D  0  E 


given  by  taking 

,,  v  /(*.»)  x  ^  J.  and  x  ^  ± 
smash(x,  y)  =  s 

{  -Ld®£  otherwise 

This  function  establishes  a  useful  relationship  between  D  x  E  and  D®  E.  In  fact,  it  is  a  projection 
whose  corresponding  embedding  is  the  function  unsmash  :  D  0  E  — ►  D  x  E  given  by 


unsmash(z) 


z  if  z  =  (x,  y)  is  a  pair 

(±,±)  if  z  =  -Ld®£ 


Let  us  say  that  a  function  f  :  D  x  E  -*  F  is  bistrict  if  f(x,y)  =  1  whenever  x  =  _L  or  y  =  1.  If 
/  :  D  x  E  —*  F  is  bistrict  and  continuous,  then  g  =  f  o  unsmash  is  the  unique  strict,  continuous 
function  which  completes  the  following  diagram: 


D  x  E 


If  /  :  D  —*  D'  and  g  :  E  — ►  E'  are  strict  continuous  functions,  then  / =  smash  o(  /  x  g)o  unsmash 
is  the  unique  strict,  continuous  function  which  completes  the  following  diagram: 


D  X  E 


f*9 


D  %E 


smash 
D  <0  E 


f®9 


smash 

D  <g)  E 


As  with  the  product  x  and  function  space  — ,  there  is  a  relationship  between  the  smash  product 
9)  and  the  strict  function  space  o— ►.  In  particular,  there  is  a  strict  continuous  function  strict_apply 
such  that  for  any  strict  function  /,  there  is  a  unique  strict  function  strict.curry  such  that  the 
following  diagram  commutes: 


D  ®  E 


strict_curry(/)  0  id 


1 


[E  o-*  F)  0  E 


strict.apply 
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1.4.4  Sums  and  lifts. 


Given  cpo’s  D  and  E ,  we  define  the  coalesced  sum  D  ©  E  to  be  the  set 

((D  -  {X»»  x  {0})  U  ((£  -  {±E})  x  {1}]  U  {±D«E} 

where  D  —  {±o}  and  E-{±e}  are  the  sets  D  and  E  with  their  respective  bottom  elements  removed 
and  ±d©e  is  a  new  element  which  is  not  a  pair.  It  is  ordered  by  taking  1 -d®e  C  z  for  all  z  €  D  ©  E 
and  taking  (x,m)  C  ( y,n )  if  and  only  if  m  =  n  and  iCy,  There  are  strict  continuous  functions 
ini  :  D  o-+(D  ©  E)  and  inr  :  E  o -+(D  ©  E)  given  by  taking 


and 


inl(x) 


inr(x) 


i 

( 


(x,  0)  if  x  ^  J. 

i-D©E  if  x  =  ± 

(x,l)  if  x  #  -L 

-1 -D®E  if  x  =  i. 


Moreover,  if  /  :  D  o-+  F  and  g  :  E  o->  F  are  strict  continuous  functions,  then  there  is  a  unique  strict 
continuous  function  [/,</]  which  completes  the  following  diagram: 


D 


E 


The  function  [f,g]  is  given  by 


[/-$](*) 


/,x)  if  z  =  (x.0) 
■  g(y)  if  z  =  (y, 1) 
_L  if  x  =  _L. 


Given  continuous  functions  /  :  D  o—  D'  and  g  :  E  o-~  E',  we  define 


/  ©  g  =  [ini  o  /,  inr  o  g]  :  D  ©  E  o->  D'  ©  E'. 


As  with  the  product,  it  is  useful  to  have  a  multiary  notation  for  the  coalesced  sum.  We  define 


and 


©0  =  1 

©(£>!,...,!>„)  =  ©(A . Dn.x)®Dn 

in,  =  inr  o  ini"-’. 
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Figure  1.2:  The  lift  of  a  cpo. 


One  may  also  define  [fi,.. .  ,/„]  and  prove  a  universal  property. 

Given  a  cpo  D ,  we  define  the  lift  of  D  to  be  the  set  £?x  =  (Z)  x  {0})  U  {-L},  where  ±  is  a  new 
element  which  is  not  a  pair,  together  with  an  partial  ordering  C  which  is  given  by  stipulating  that 
(x,0)  C  (y,  0)  when  x  Q  y  and  _L  C  z  for  every  z  £  D±.  In  short,  D±  is  the  poset  obtained  by 
adding  a  new  bottom  to  D — see  Figure  1.2.  It  is  easy  to  show  that  D±  is  a  cpo  if  D  is.  We  define 
a  strict  continuous  function  down  :  D±  o->  D  by 


down(x) 


x 

-t-£> 


if  z  —  (x,0) 
otherwise 


and  a  (non-strict)  continuous  function  up  :  Z?  — ►  D±  given  by  up  :  x  (x,0).  These  functions  are 
related  by 

down  o  up  =  idp 
up  o  down  □  id£>x 

These  inequations  are  reminiscent  of  those  which  we  gave  for  embedding- projection  pairs,  but  the 
second  inequation  has  □  rather  than  C.  We  will  discuss  such  pairs  of  functions  later.  Given  cpo's 
D  and  E  and  continuous  function  /  :  D  — *•  E,  there  is  a  unique  strict  continuous  function  which 
completes  the  following  diagram: 


D 


Given  a  continuous  function  f  :  D  —*  E,  we  define  a  strict  continuous  function 

/x  =  (upo/)t  :  Z}x°-£l- 
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Given  cpo’s  D  and  E,  we  define  the  separated  sum  D  +  E  to  be  the  epo  D±  ©  E±.  By  the 
universal  properties  for  ©  and  (-)j.,  we  know  that  h  =  [/*,5*]  is  the  unique  strict  continuous 
function  which  completes  the  following  diagram: 

D 

in  o  up 
D-- 
inr  o  up 

E 

However,  h  may  not  be  the  only  continuous  function  which  completes  the  diagram.  Given  contin¬ 
uous  functions  /  :  D  — ►  D'  and  g  :  E  — *  E' ,  we  define 

/  +  P  =  /x®5jl  ■  D  +  E  — *  D'  +  E' . 

1.4.5  Isomorphisms  and  closure  properties. 

There  are  quite  a  few  interesting  relationships  between  the  operators  above  which  are  implied  by 
the  definitions  and  commutative  diagrams.  We  list  a  few  of  these  in  the  following  lemmas. 

» 

Lemma  8  Let  D,  E  and  F  be  cpo’s,  then 

1.  D  x  E  St  E  x  D, 

2.  (D  x  E)  x  F  2  D  x  {E  x  F), 

3.  D  —>  (E  x  F)  =  (D  E)  x  (D  -*  F), 

4-  D  -  (E  -+  F)  *  (D  x  E)  -  F.  | 

Lemma  9  Let  D,  E  and  F  be  cpo’s,  then 

1.  D  <g>  E  SS  E  0  D, 

2.  (D  ®  E)®  F  2  D  ®{E  ®  F), 

5.  (£  ©  F)  o-*  D  £  {£  o-*  £>)  x  (£  o-*  F), 

4.  D°-*(Eo*F)  3  (1?®  E)o->F, 

5.  £>®(£©F)2(£>®  £)©(£®£) 

6.  D±  o—  £  *  £>  —  £.  | 
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We  remarked  already  that  D  —*  E  and  D  o— <•  E  are  bounded  complete  domains  whenever  D  and 
E  are.  It  is  not  difficult  to  see  that  similar  closure  properties  will  hold  for  the  other  operators  we 
have  defined  in  this  section: 

Lemma  10  If  D  and  E  are  bounded  complete  domains  then  so  are  the  cpo’s  D  —  E,  Do—E, 
D  x  E,  D  ®  E,  D  -4-  E,  D  0  E,  D±.  | 

Further  discussion  of  the  operators  defined  in  this  section  and  others  may  be  found  in  [Sco82a] 
and  [Sco82b]. 
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1.5  Powerdomains. 


We  now  turn  our  attention  to  another  collection  of  operators  on  domains.  Just  as  we  have  defined 
a  computable  analog  to  the  function  space,  we  will  now  define  a  computable  analog  to  the  powerset 
operation.  Actually,  we  will  produce  three  such  operators.  In  the  domain  theory  literature  these 
are  called  powerdomains.  If  D  is  a  domain  we  write 

•  £>s  for  the  upper  powerdomain  of  D, 

•  D 11  for  the  convex  powerdomain  of  D,  and 

•  Db  for  the  lower  powerdomain  of  D. 

The  names  we  use  for  these  operators  come  from  the  concepts  of  upper  and  lower  semi-continuity 
and  the  interested  reader  can  consult  [Smy83b]  for  a  detailed  explanation.  They  commonly  appear 
under  other  names  as  well.  The  convex  powerdomain  D*  was  introduced  by  Gordon  Plotkin  [Plo76] 
and  is  therefore  sometimes  referred  to  as  the  Plotkin  powerdomain.  The  upper  powerdomain  Dt  was 
introduced  by  Mike  Smyth  [Smy78]  and  is  sometimes  called  the  Smyth  powerdomain.  For  reasons 
that  we  will  discuss  briefly  below,  this  latter  powerdomain  corresponds  to  the  total  correctness 
interpretation  of  programs.  Since  Tony  Hoare  has  done  much  to  popularize  the  study  of  partial 
correctness  properties  of  programs,  the  remaining  powerdomain  Db — which  corresponds  to  the 
partial  correctness  interpretation — sometimes  bears  his  name. 

1.5.1  Intuition. 

There  is  a  basic  intuition  underlying  the  powerdomain  concept  which  can  be  explained  through 
the  concept  of  partial  information.  To  keep  things  simple,  let  us  assume  that  we  are  given  a  finite 
poset  A  and  asked  to  form  the  poset  of  finite  non-empty  subsets  of  A.  As  a  first  guess,  one  might 
take  the  non-empty  subsets  and  order  them  by  subset  inclusion.  However,  this  operation  ignores 
the  order  structure  on  A!  Think  of  A  as  a  collection  of  partial  descriptions  of  data  elements:  x  C  y 
just  in  case  x  is  a  partial  description  of  y.  What  should  it  mean  for  one  non-empty  subset  of  A 
to  be  a  “partial  description”  of  another?  The  are  at  least  three  reasonable  philosophies  that  one 
might  adopt  in  attempting  to  answer  this  question. 

Suppose,  for  example,  that  I  hold  a  bag  of  fruit  and  I  wish  to  give  you  information  about  what 
is  in  the  bag.  One  such  description  might  be 

A  fruit  in  the  bag  is  a  yellow  fruit  or  a  red  fruit. 

This  description  is  based  on  two  basic  pieces  of  data:  “is  a  yellow  fruit”  and  “is  a  red  fruit”.  These 
are  used  to  restrict  the  kinds  of  fruit  which  are  in  the  bag.  A  more  informative  description  of  this 
kind  would  provide  further  restrictions.  Consider  the  following  example: 

A  fruit  in  the  bag  is  a  yellow  fruit  or  a  cherry  or  a  strawberry. 


It  is  based  on  three  pieces  of  data:  “is  a  yellow  fruit”,  “is  a  cherry”  and  “is  a  strawberry”.  Since 
these  three  data  provide  further  restrictions  on  the  contents  of  the  bag  (by  ruling  out  the  possibility 
of  an  apple,  for  example)  it  is  a  more  informative  statement  about  the  bag’s  contents.  On  the  other 
hand, 

A  fruit  in  the  bag  is  a  yellow  fruit  or  a  red  fruit  or  a  purple  fruit. 

is  a  less  informative  description  because  it  is  more  permissive;  for  instance,  it  does  not  rule  out 
the  possibility  that  the  bag  holds  a  grape.  Now  suppose  that  u,  v  are  subsets  of  the  poset  A  from 
the  previous  paragraph.  With  this  way  of  seeing  things,  we  should  say  that  u  is  below  v  if  the 
restrictions  imposed  by  v  axe  refinements  of  the  restrictions  imposed  by  u:  that  is,  for  each  y  €  v, 
there  is  an  x  €  u  such  that  iCy,  This  is  the  basic  idea  behind  the  upper  powerdomain  of  A. 

Returning  to  the  bag  of  fruit  analogy,  we  might  view  the  following  as  a  piece  of  information 
about  the  contents  of  the  bag 

There  is  some  yellow  fruit  a ad  some  red  fruit  in  the  bag. 

This  information  is  based  on  two  pieces  of  data:  “is  a  yellow  fruit”  and  “is  a  red  fruit”.  However, 
these  data  are  not  being  used  as  before.  They  do  not  restrict  possibilities;  instead  they  offer  a 
positive  assertion  about  the  contents  of  the  bag.  A  more  informative  description  of  this  kind  would 
provide  a  further  enumeration  and  refinement  of  the  contents: 

There  is  a  banana,  a  cherry  and  some  purple  fruit  in  the  bag. 

This  refined  description  does  not  rule  out  the  possibility  that  the  bag  holds  a  apple,  but  it  does 
insure  that  there  is  an  cherry.  A  statment  such  as 

There  is  some  yellow  fruit  in  the  bag. 

is  less  informative  since  it  does  not  mention  the  presence  of  red  fruit.  Now  suppose  that  u.  v  are 
subsets  of  the  poset  A.  With  this  way  of  seeing  things,  we  should  say  that  u  is  below  v  if  the 
positive  assertions  provided  by  u  are  extended  and  refined  by  v:  that  is,  for  each  x  6  u,  there  is  a 
y  €  v  such  that  x  C  y.  This  is  the  basic  idea  behind  the  lower  powerdomain  of  A. 

Now,  the  convex  powerdomain  combines  these  two  forms  of  information.  For  example,  the 
assertion 

If  you  pull  a  fruit  from  the  bag,  then  it  must  be  yellow  or  a  cherry,  and  you  can  pull  a 
yellow  fruit  from  the  bag  and  you  can  pull  a  cherry  from  the  bag. 

is  this  combined  kind  of  information.  The  pair  of  assertions  means  that  the  bag  holds  some  yellow 
fruit  and  at  le-st  one  cherry,  but  nothing  else.  A  more  refined  description  might  be 

If  you  pull  a  fruit  from  the  bag,  then  it  must  be  a  banana  or  a  cherry,  and  you  can  pull 
a  banana  from  the  bag  and  you  can  pull  a  cherry  from  the  bag. 

A  less  refined  description  might  be 
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If  you  pull  a  fruit  from  the  bag,  then  it  must  be  yellow  or  red,  and  you  can  pull  a  yellow 
fruit  from  the  bag  and  you  can  pull  a  red  fruit  from  the  bag. 

The  reader  may  be  curious  about  what  bags  of  fruit  have  to  do  with  programming  semantics.  The 
powerdomains  are  used  to  model  non-deterministic  computations  where  one  wishes  to  speak  about 
the  set  of  outcomes  or  a  computation.  How  one  wishes  to  describe  such  outcomes  will  determine 
which  of  the  three  powerdomains  is  used.  We  will  attempt  to  illustrate  this  idea  later  in  this 
section — when  we  have  given  some  formal  definitions. 

1.5.2  Formal  definitions. 

In  order  to  give  the  definitions  of  the  powerdomains,  it  is  helpful  to  have  a  little  information  about 
the  representation  of  domains  using  the  concept  of  a  pre-order: 

Definition:  A  pre-order  is  a  set  A  together  with  a  binary  relation  h  which  is  reflexive  and  transitive. 

It  is  conventional  to  think  of  the  relation  a  1-  b  as  indicating  that  a  is  “larger”  than  b  (as  in 
mathematical  logic,  where  <j>  1-  means  that  the  formula  ip  follows  from  the  hypothesis  <*>).  Of 
course,  any  poset  is  also  a  pre-order.  On  the  other  hand,  a  pre-order  may  fail  to  be  a  poset  by  not 
satisfying  the  anti-symmetry  axiom.  In  other  words,  we  may  have  x  by  and  y  h  x  but  x  ^  y.  By 
identifying  elements  x,y  which  satisfy  x  h  y  and  y  H  i,  we  obtain  an  induced  partially  ordered  set 
from  a  pre-order  (and  this  why  they  are  called  pre-orders).  We  shall  be  particularly  interested  in 
a  special  kind  of  subset  of  a  pre-order: 

Definition:  An  ideal  over  a  pre-order  (A,  b)  is  a  subset  s  C  A  such  that 

1.  if  u  C  3  is  finite,  then  there  is  an  x  €  3  such  that  x  I-  y  for  each  y  g  u,  and 

2.  if  x  6  s  and  x  h  y,  then  y  €  s.  | 

In  short,  an  ideal  is  a  subset  which  is  directed  and  downward  closed.  If  x  £  A  for  a  pre-order  A. 
then  the  set 

lx  =  {yeA\xb-y) 

is  an  ideal  called  the  principal  ideal  generated  by  x.  To  induce  a  poset  from  a  pre-order,  one  can 
take  the  poset  of  principal  ideals  under  set  inclusion.  The  poset  of  all  ideals  on  a  pre-order  is 
somewhat  more  interesting: 

Theorem  11  Given  a  countable  pre-order  (A,H),  let  D  be  the  poset  consisting  of  the  ideals  over 
A,  ordered  by  set  inclusion.  If  there  is  an  element  ±  €  A  such  that  x  h  i  for  each  x  g  A,  then  D 
is  a  domain  and  K(D)  is  the  set  of  principal  ideals  over  A. 

Proof:  Clearly,  the  ideals  of  A  form  a  poset  under  set  inclusion  and  the  principal  ideal  J,  ±  is  the 
least  element.  To  see  that  this  poset  is  complete,  suppose  that  M  C  D  and  let  x  =  \JM .  If  we  can 
show  that  x  is  an  ideal,  then  it  is  certainly  the  least  upper  bound  of  M  in  D.  To  this  end,  suppose 
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u  C  x  is  finite.  Since  each  element  of  u  must  be  contained  in  some  element  of  M,  there  is  a  finite 
collection  of  ideals  s  C  M  such  that  if  C  Us.  Since  M  is  directed,  there  is  an  element  y  e  M  such 
that  z  C  y  for  each  z  €  s.  Thus  u  C  y  and  since  y  is  ideal,  there  is  an  element  a  e  y  such  that 
b  C  a  for  each  6  6  it.  But  a  €  y  C  x,  so  it  follows  that  x  is  an  ideal. 

To  see  that  D  is  a  domain,  we  show  that  the  set  of  principal  ideals  is  a  basis.  Suppose  M  C  D 
is  directed  and  I  a  C  U-^  for  some  a  €  A.  Then  a  S  i  for  some  x  e  M,  so  la  C  x.  Hence  [  a 
is  compact  in  D.  Now  suppose  x  e  D  and  u  C  A  is  a  finite  collection  of  elements  of  A  such  that 
l  a  C  x  for  each  a  e  u.  Then  u  C  x  and  since  x  is  an  ideal,  there  is  an  element  b  £  x  with  b  \-  a 
for  each  a  6  u.  Thus  |  o  C  j  b  for  each  a  £  u  and  it  follows  that  the  principal  ideals  below  x  form 
a  directed  collection.  It  is  obvious  that  the  least  upper  bound  (i.e.  union)  of  that  collection  is  x. 
Since  x  was  arbitrary,  it  follows  that  D  is  an  algebraic  cpo  with  principal  ideals  of  .4  as  its  basis. 
Since  A  is  countable,  there  are  only  countably  many  principal  ideals,  so  D  is  a  domain.  | 

For  any  set  5,  we  let  Vj(S)  be  the  set  of  finite  non-empty  subsets  of  5.  We  write  Vf(S)  for 
the  set  of  all  finite  subsets  (including  the  empty  set).  Given  a  poset  (A,C),  define  a  pre-ordering 
l-8  on  Vf(A)  as  follows, 

uh't;  if  and  only  if  (Vx  e  u)(3y  6  v).  x  □  y. 

Dually,  define  a  pre-ordering  I-1’  on  Vj(A)  by 

u  K  v  if  and  only  if  (Vy  €  u)(3x  €  u).  x  □  y. 

And  define  h8  on  Vj(A)  by 

u  h8  v  if  and  only  if  nMv  and  u  h1’  v. 

If  D  is  a  domain,  then  let  Dn  be  the  domain  of  ideals  over  (Vj(I\(D)),  H).  We  call  D3  thf>  convex 
powerdomain  of  D.  Similarly,  define  and  Db  to  be  the  domains  of  ideals  over  ('PJ(K(D)),\-i)  and 
(V](K(D)),  hb)  respectively.  We  call  Di  the  upper  powerdomain  of  D  and  £>b  the  lower  powerdomain 
of  D. 

As  an  example,  we  compute  the  lower  powerdomain  of  Nx-  Since  A'(Nx)  =  the  lower 
powerdomain  of  Nx  is  the  set  of  ideals  over  the  pre-order  (^(Nx),^1’).  To  see  what  such  an  ideal 
must  look  like,  note  first  that  {J.}  and  uU  {-L}  l~b  u  for  any  u  e  'P’INx).  From  this  fact  it 

is  already  possible  to  see  why  !-b  is  usually  only  a  pre-order  and  not  a  poset.  Now,  if  u  and  v  both 
contain  _L,  then  u  hb  v  iff  u  D  v.  Hence  we  may  identify  an  ideal  x  6  (Nx)*  with  the  union  (J1  of 
all  the  elements  in  x.  Thus  (Nx)b  is  isomorphic  to  the  domain  PN  of  all  subsets  of  N  under  subset 
inclusion. 

Now  let  us  compute  the  upper  powerdomain  of  Nx-  Note  that  if  u  and  v  are  finite  non-empty 
subsets  of  Nx  and  lev,  then  u  I-8  v.  In  particular,  any  ideal  x  in  (Nx)8  contains  all  of  the  finite 
subsets  v  of  Nx  with  lev.  So,  let  us  say  that  a  set  u  e  ^/(Ni)  is  non-trivial  if  it  does  not 
contain  1  and  an  ideal  x  e  (Nx)8  is  non-trivial  if  there  is  a  non-trivial  u  e  x.  Now.  if  u  and  v  are 
non-trivial,  then  u  h8  v  iff  u  C  v.  Therefore,  if  an  ideal  x  is  non-trivial,  then  it  is  the  principal  ideal 
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generated  by  the  intersection  of  its  non-trivial  elements!  The  smaller  this  set  is,  the  larger  is  the 
ideal  x.  Hence,  the  non-trivial  ideals  in  the  powerdomain  (ordered  by  subset  inclusion)  correspond 
to  finite  subsets  of  N  (ordered  by  superset  inclusion).  If  we  now  throw  in  the  unique  trivial  ideal,  we 
can  see  that  (Nj.)#  is  isomorphic  to  the  domain  of  sets  {N}  U  'PJ(N)  ordered  by  superset  inclusion. 
Finally,  let  us  look  at  the  convex  powerdomain  of  If  u,v  £  £*J(N x)>  then  u  h!  v  iff 

1.  JL  €  v  and  u  3  v  or 

2.  u  =  v 

Hence,  if  x  is  an  ideal  and  there  is  a  set  u  £  x  with  J.  £  u,  then  x  is  the  principal  ideal  generated 
by  u.  No  two  distinct  principal  ideals  like  this  will  be  comparable.  On  the  other  hand,  if  x  is  an 
ideal  with  J.  £  u  for  each  u  £  x,  then  x  C  y  for  an  arbitrary  ideal  y  iff  (Jx  C  (J  2/-  Thus  the  convex 
powerdomain  of  Nx  corresponds  to  the  set  of  finite,  non-empty  subsets  of  N  unioned  with  the  set 
of  arbitrary  subsets  of  Nx  that  contain  _L.  The  ordering  on  these  sets  is  like  the  pre-ordering  h1 
but  extended  to  include  infinite  sets. 

1.5.3  Universal  and  closure  properties. 

If  s,t  €  then  we  define  a  binary  operation 

s  U  t  =  {w  |  u  U  v  h11  w  for  some  u  £  s  and  v  £  t}. 

This  set  is  an  ideal  and  the  function  U  :  D*  X  D*  -*  D*  is  continuous.  Similar  facts  apply  when  U 
is  defined  in  this  way  for  D 11  and  D*.  Now,  if  x  £  D,  define 

^x}  =  {u  £  Vf(K(D))  |  {xo}  H11  u  for  some  compact  x0  C  x}. 

This  forms  an  ideal  and  {-J  :  D  — ►  is  a  continuous  function.  When  one  replaces  H  in  this 
definition  by  I-11  or  I-",  then  similar  facts  apply.  Strictly  speaking,  we  should  decorate  the  symbols 
U  and  -J-J  with  indices  to  indicate  their  types,  but  this  clutters  the  notation  somewhat.  Context 
will  determine  what  is  intended. 

These  three  operators  (-)**,  (-)b  and  (-)11  may  not  seem  to  be  the  most  obvious  choices  for  the 
computable  analog  of  the  powerset  operator.  We  will  attempt  to  provide  some  motivation  for 
choosing  them  in  the  remainder  of  this  section.  Given  the  operators  U  and  we  may  say  that  a 
point  x  £  D  for  a  domain  D  is  an  “element”  of  a  set  s  in  a  powerdomain  of  D  if  -Jx[)  U  s  =  s.  If  s 
and  t  lie  in  a  powerdomain  of  D,  then  s  is  a  “subset”  of  t  if  sU  t  =  t.  Care  must  be  taken,  however, 
not  to  confuse  “sets”  in  a  powerdomain  with  sets  in  the  usual  sense.  The  relations  of  “element” 
and  “subset”  described  above  will  have  different  properties  in  the  three  different  powerdomains. 
Moreover,  it  may  be  the  case  that  s  is  a  “subset”  of  t  without  it  being  the  case  that  $  C  t\ 

To  get  some  idea  how  the  powerdomains  are  related  to  the  semantics  of  non-deterministic 
programs,  let  us  discuss  non-deterministic  partial  functions  from  N  to  N.  As  we  have  noted  before, 
there  is  a  correspondence  between  partial  functions  from  N  to  N  and  strict  functions  /  :  Nx  o—  Nx- 
These  may  be  thought  of  as  the  meanings  of  “deterministic”  programs,  because  the  output  of 
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a  program  is  uniquely  determined  by  its  input  (i.e.  the  meaning  is  a  partial  function).  Suppose, 
however,  that  we  are  dealing  with  programs  which  permit  some  finite  non- determinism  as  discussed 
in  the  section  on  non-determinism  in  the  chapter  of  Peter  Mosses.  Then  we  may  wish  to  think  of  a 
program  as  having  as  its  meaning  a  function  /  :  Nx  — »  P(NX)  where  P  is  one  of  the  powerdomains. 
For  example,  if  a  program  may  give  a  1  or  a  2  as  an  output  when  given  a  0  as  input,  then  we 
will  want  the  meaning  /  of  this  program  to  satisfy  /( 0)  =  -JlJ-U  -J25-  =  )|1,2J.  The  three  different 
powerdomains  reflect  three  different  views  of  how  to  relate  the  various  possible  program  behaviors 
in  the  case  of  divergence.  The  upper  powerdomain  identifies  program  behaviors  which  may  diverge. 
For  example,  if  program  Pi  can  give  output  1  or  diverge  on  any  of  its  inputs,  then  it  will  be 
identified  with  the  program  Q  which  diverges  everywhere,  since  |1,X|  =  -L  =  •j]-L|}'  in  (Nx)5. 
However,  program  a  P2  which  always  gives  1  as  its  output  (on  inputs  other  than  X)  will  not  have 
the  same  meaning  as  Pi  and  Ax.  X.  On  the  other  hand,  if  the  lower  powerdomain  is  used  in  the 
interpretation  of  these  programs,  then  Pi  and  P2  will  be  given  the  same  meaning  since  -J 1 ,  X|}-  =  f]l|} 
in  (Nx)b-  However,  Pi  and  P2  will  not  have  the  same  meaning  as  the  always  divergent  program 
Q  since  -Jl,X&  X  in  the  lower  powerdomain.  Finally,  in  the  convex  powerdomain,  none  of  the 
programs  Pi,  P2,  Q  have  the  same  meaning  since  -Jl,X^,  $1^  and  $X}-  are  all  distinct  in  (Nx)“- 
To  derive  properties  of  the  powerdomains  like  those  that  we  discussed  in  the  previous  section 
for  the  other  operators,  we  need  to  introduce  the  concept  of  a  domain  with  binary  operator. 

Definition:  A  continuous  algebra  (of  signature  (2))  is  a  cpo  E  together  with  a  continuous  binary 
function  *  :  E  x  E  — *  E.  We  refer  to  the  following  collection  of  axioms  on  *  as  theory  T6: 

1.  associativity:  (r  *  3)  *  t  =  r  *  (s  *  t) 

2.  commutativity:  r  *  3  =  s  *  r 

3.  idempotence:  3  *  3  =  s. 

(These  are  the  well-known  semi-lattice  axioms.)  A  homomorphism  between  continuous  algebras  D 
and  £  is  a  continuous  function  /  :  D  — *  E  such  that  f(s  *  t)  =  f(s)  *  f(t)  for  all  sj  €  D.  | 

It  is  easy  to  check  that,  for  any  domain  £>,  each  of  the  algebras  Di,  and  Db  satisfies  T3. 
However,  ZP  is  the  “free”  continuous  algebra  over  D  which  satisfies  T*: 

Theorem  12  Let  D  be  a  domain.  Suppose  (E,*)  is  a  continuous  algebra  which  satisfies  T3 .  For 
any  continuous  f  :  D  —  E,  there  is  a  unique  homomorphism  ext (/)  :  — *  E  which  completes  the 

following  diagram: 


D 
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Proof:  (Hint)  If  u  =  {zi,...,xn}  6  s  6  Dh,  and  u  is  the  principal  ideal  generated  by  u,  then 
define  ext(/)(ii)  =  f(x i)  *  •  •  •  *  f(xn ).  This  function  has  a  unique  continuous  extension  to  all  of  D 5 
given  by  ext(/)(s)  =  L){ext(/)(u)  1  «  €  a}.  I 

Now,  consider  the  following  axiom: 

4s.  3U  t  C  s. 

Let  T 3  be  the  set  of  axioms  obtained  by  adding  axiom  4®  to  the  axioms  in  T 3.  Similarly,  let  rb  be 
obtained  by  adding  the  axiom 

4".  s  c  s  u  t 

to  the  axioms  in  T*.  The  point  is  this:  Theorem  12  still  holds  when  D 3  and  T 11  are  replaced  by  Di 
and  T3  respectively,  or  by  D”  and  T9  respectively. 

As  was  the  case  with  the  smash  product  and  lift  operators,  a  diagram  like  the  one  in  Theorem  12 
gives  rise  to  another  important  operation  on  functions.  If  /  :  D  — *  E  is  a  continuous  function,  then 
there  is  a  unique  homomorphism  /5  which  completes  the  following  diagram: 

f 

D  - -  E 

u 

f'  l 

Dk - -  Ek 

Namely,  one  defines  =  ext(M  o  /).  Of  course,  there  are  functions  /a  and  /’  with  similar 
definitions. 

Two  of  the  powerdomains  preserve  the  property  of  bounded  completeness: 

Lemma  13  If  D  is  a  bounded  complete  domain  then  so  are  D a  and  . 

Proof:  We  leave  for  the  reader  the  exercise  of  showing  that  a  domain  D  is  bounded  complete  if 
and  only  if  every  finite  bounded  subset  of  its  basis  has  a  least  upper  bound.  To  see  that  D°  is 
bounded  complete,  just  note  that,  for  any  pair  of  sets  u,  v  6  Vj(K(D)),  the  ideal  generated  by 
their  union  u  U  v  is  the  least  upper  bound  in  Db  for  the  ideals  generated  by  u  and  v.  To  see  that 
Di  is  bounded  complete,  suppose  u,v,w  €  Vj(K(D))  with  w  b3  u  and  w  h3  v.  Let  w'  be  the  set  of 
elements  z  6  K{D)  such  that  there  are  elements  x  G  u  and  y  6  v  and  z  is  the  least  upper  bound 
of  {x.y}.  The  set  w'  is  non-empty  because  {u,u}  is  bounded.  Moreover,  it  is  not  hard  to  see  that 
w  w 1  and  w'  M  u  and  w'  I-3  v.  Hence  the  ideal  generated  by  w'  is  the  least  upper  bound  of  the 
ideals  generated  by  u  and  v.  | 
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1.6  Bifinite  domains. 


Of  the  operators  that  we  have  discussed  so  far,  only  the  convex  powerdomain  (-)11  does  not  take 
bounded  complete  domains  to  bounded  complete  domains.  To  see  this  in  a  simple  example,  consider 
the  finite  poset  T  x  T  and  the  following  elements  of  Vj(T  x  T): 

tt  =  {{-L, true),  (J_, false)} 
v  =  {{true,  -L),  (false,  ±)} 
u'  =  {{true,  true),  (false, false)} 
v'  =  {(true, false),  (false, true)} 

It  is  not  hard  to  see  that  u'  and  v'  are  minimal  upper  bounds  for  {u,  u}  with  respect  to  the  ordering 
M.  Hence  no  least  upper  bound  for  {u,  u'}  exists  and  (T  x  T)1*  is  therefore  not  bounded  complete.  In 
this  section  we  introduce  a  natural  class  of  domains  on  which  all  of  the  operators  we  have  discussed 
above  (including  the  convex  powerdomain)  are  closed.  This  class  is  defined  as  follows: 

Definition:  Let  D  be  a  cpo.  Let  M  be  the  set  of  finitary  projections  with  finite  image.  Then  D 
is  said  to  be  bifinite  if  M  is  countable,  directed  and  |J M.  —  id.  | 

The  bifinite  cpo’s  are  motivated,  in  part,  by  considerations  from  category  theory  and  the  definition 
above  is  a  restatement  of  their  categorical  definition.  They  were  first  defined  by  Plotkin  [Plo76] 
(where  they  are  called  “SFP-objects”)  and  the  term  “bifinite”  is  due  to  Paul  Taylor.  Bifinite 
domains  (and  various  closely  related  classes  of  cpo’s)  have  also  been  discussed  under  other  names 
such  as  “strongly  algebraic”  [Smy83a,  Gun86]  and  “profinite”  [Gun87]  domains. 

1.6.1  Plotkin  orders. 

As  we  suggested  earlier,  the  image  of  a  finitary  projection  p  :  D  —  D  on  a  domain  D  can  be 
viewed  as  an  approximation  to  D.  A  bifinite  domain  is  one  which  is  a  directed  limit  of  its  finite 
approximations.  But  what  is  this  really  saying  about  the  structure  of  D ?  First  of  all.  it  follows  from 
properties  of  finitary  projections  that  we  mentioned  earlier  that  whenever  p  :  D  —  D  is  a  finitary 
projection  and  im(p)  is  finite,  then  im(p)  C  K(D).  From  this,  together  with  the  fact  that  the  set 
M  is  directed  and  \_\M  =  id,  it  is  possible  to  show  D  is  a  domain  with  (J{im(p)  |  p  €  M}  as  its 
basis.  We  may  now  use  the  correspondence  which  we  noted  in  Theorem  6  to  provide  a  condition 
on  the  basis  of  a  domain  which  characterizes  the  domain  as  being  bifinite.  Recall  that  .V  <  A  for 
posets  N  and  A  if  TV  n  i  x  is  directed  for  every  x  £  A. 

Definition:  A  poset  A  is  a  Plotkin  order  if,  for  every  finite  subset  u  C  A,  there  is  a  finite  set  .V  <j  A 
with  uCi\T.| 


Theorem  14  The  following  are  equivalent  for  any  cpo  D. 


1.  D  is  bifinite. 


o 


a.  b.  c- 


Figure  1.3:  Posets  that  are  not  Plotkin  orders. 

2.  D  is  a  domain  and  K(D )  is  a  Plotkin  order.  | 

To  get  some  idea  what  a  Plotkin  order  looks  like,  it  helps  to  have  a  definition.  Given  a  poset  A 
and  a  finite  set  uC  A,an  upper  bound  x  for  u  is  minimal  if,  for  any  upper  bound  y  for  u,  y  C  x 
implies  y  =  x.  A  set  v  of  minimal  upper  bounds  for  u  is  said  to  be  complete  if,  for  every  upper 
bound  x  for  u,  there  is  a  y  6  v  with  y  C  x.  Now,  let  A  be  a  Plotkin  order  and  suppose  u  C  A  is 
finite.  Then  there  is  a  finite  N  «  A  with  u  C  N .  The  set  N  must  contain  a  complete  set  of  minimal 
upper  bounds  for  u  (why?).  This  shows  the  first  fact  about  Plotkin  orders:  every  finite  subset  has 
a  complete  set  of  minimal  upper  bounds.  This  rules  out  configurations  like  the  one  pictured  in 
Figure  1.3a  where  the  pair  of  points  indicated  by  closed  circles  do  not  have  such  a  complete  set 
of  minimal  upper  bounds.  But  the  set  N  is  finite  so  we  have  our  second  fact:  every  finite  subset 
must  have  a  finite  complete  set  of  minimal  upper  bounds.  This  rules  out  configurations  like  tm^one 
pictured  in  Figure  1.3b  where  the  pair  of  points  indicated  by  closed  circles  has  a  complete  set  of 
minimal  upper  bounds  but  not  a  finite  one.  However,  having  finite  complete  sets  of  minimal  upper 
bounds  for  finite  subsets  is  not  a  sufficient  condition  for  characterizing  the  Plotkin  orders.  1  j  see 
why,  let  A  be  a  poset  which  has  finite  complete  sets  of  minimal  upper  bounds  for  finite  subsets.  If 
u  C  A  is  finite,  let 

U{u)  =  {x  |  x  is  the  minimal  upper  bound  for  some  v  C  u}. 

Now,  if  u  C  N  <A,  then  U{u)  C  N.  Hence,  Un(u)  C  N  for  each  n.  If  N  is  finite,  then  there  must  be 
an  n  for  which  Un{u)  =  Un+l{u).  This  is  a  third  fact  about  Plotkin  orders:  for  each  finite  u  C  A. 
£V°°(u)  =  (Jn£/n(u)  is  finite.  To  see  what  can  go  wrong,  note  that  f/°°( u)  is  infinite  when  u  is  the 
pair  of  points  indicated  by  closed  circles  in  Figure  1.3c. 

1.6.2  Closure  properties. 

Proposition  15  A  bounded  complete  domain  is  bifinite. 
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Proof:  Suppose  D  is  bounded  complete  and  u  C  K{D)  is  a  finite  subset  of  the  basis  of  D.  Let 
N  =  {x  |  i  is  the  least  upper  bound  of  a  finite  subset  of  u  }. 


Note  that  N  is  finite;  we  claim  that  N  <  K(D).  Suppose  x  is  the  least  upper  bound  of  a  finite  set 
v  C  K(D).  Since  D  is  algebraic,  there  is  a  directed  subset  M  C  K{D)  such  that  x  =  jj.l/.  But 
the  elements  of  v  axe  compact.  Hence,  for  every  y  G  v,  there  is  a  y'  G  M  with  y  C  y' .  Since  M 
is  directed,  there  is  some  z  G  M  which  is  an  upper  bound  for  v.  Now,  z  C  x  so  x  =  z  and  x  is 
therefore  compact.  This  shows  that  N  C  K(D).  Suppose  v  C  N  is  bounded,  then  the  least  upper 
bound  of  v  is  the  same  as  the  least  upper  bound  of  the  set  {x  G  u  |  x  C  y  for  some  y  G  u}  so  the 
least  upper  bound  of  v  is  in  N.  Now,  if  x  G  K(D ),  then  S  =  (lx)  H  N  is  bounded.  Since  5  has  a 
least  upper  bound  which,  apparently,  lies  in  S,  we  conclude  that  5  is  directed.  | 

Theorem  16  If  D  is  bifinite,  then  the  poset  Fp (D)  of  finitary  projections  on  D  is  an  algebraic 
lattice  and  the  inclusion  map  i :  Fp (D)  *— *  (D  — *  D)  is  an  embedding. 

Proof:  (Sketch)  One  uses  Theorem  6  to  show  that  Fp(JD)  is  an  algebraic  lattice.  Suppose 
/  :  D  — *■  D  is  continuous.  Let 

Sf  =  {x  €  K(D)  |  x  C  /(x)}. 

One  can  show  that  there  is  a  least  set  Nj  such  that  5/  C  Nj<K{D).  This  set  determines  a  finitary 
projection  pN/  as  in  the  discussion  before  Theorem  6.  On  the  other  hand,  if  /  :  D  -*  D  is  a  finitary 
projection  then  Nf  =  im(/)  n  K(D )  and  /  =  p^f.  The  remaining  steps  required  to  verify  that 
/  •-»  Nf  is  a  projection  are  straight- forward.  | 

Lemma  17  If  D  and  E  are  bifinite  domains,  then  so  are  the  cpo’s  D  — *  E,  D  o—  E ,  D  x  E.  D<2>  E. 
D  •+■  E,  D  ©  E,  D±,  D\  D ®  and  D 

Proof:  We  will  outline  proofs  for  two  sample  cases.  We  begin  with  the  function  space  operator. 
Suppose  p  :  D  — *•  D  and  q  :  E  — *  E  are  finitary  projections.  Given  a  continuous  function  /  :  D  — ►  E, 
define  0 (q,p){f)  =  qQf°P •  The  function  Q(q,p)  defines  a  finitary  projection  on  D  —  E.  Moreover, 
if  p  and  q  have  finite  images,  then  so  does  Q(q,p).  If  we  let  M  be  the  set  of  functions  Q{q,p)  such 
that  p  and  q  are  finitary  projections  with  finite  image,  then  it  is  easy  to  see  that  [J.V(  =  id.  Hence 
D  —  E  is  bifinite.  We  will  encounter  the  function  0  again  in  the  next  section. 

To  see  that  D 11  is  bifinite,  one  shows  that  the  set 

=  {p15  |  p  E  Fp(Z?)  and  im(p)  is  finite} 

is  directed  and  has  the  identity  as  its  least  upper  bound.  The  functions  in  are  themselves  finitary 
projections  with  finite  images  so  D*  is  bifinite.  | 

One  may  conclude  from  this  lemma  that  the  bifinite  domains  have  rather  robust  closure  prop¬ 
erties.  But  there  is  something  else  about  bifinite  domains  which  makes  them  special.  They  are  the 
largest  class  of  domains  which  are  closed  under  the  operators  listed  in  the  Lemma.  In  fact,  there  is 
the  following: 
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Theorem  18  If  D  and  D  —*■  D  are  domains,  then  D  is  bifinite.  | 

The  theorem  is  due  to  Smyth  and  its  proof  may  be  found  in  [Smy83a].  It  is  carried  out  by 
analyzing  each  of  the  cases  pictured  in  Figure  1.3  and  showing  that  if  D  — *  D  is  not  a  domain,  then 
D  cannot  be  bifinite.  A  similar  result  for  the  bounded  complete  domains  can  be  found  r  [Gun86]. 
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1.7  Recursive  definitions  of  domains. 


Many  of  the  data  types  that  arise  in  the  semantics  of  computer  programming  languages  may  be 
seen  as  solutions  of  recursive  domain  equations.  Consider,  for  example,  the  equation  T  =  T  +  T  (of 
course,  this  is  an  isomorphism  rather  than  an  equality ,  but  let  us  not  make  much  of  this  distinction 
for  the  moment).  How  would  we  go  about  finding  a  domain  which  solves  this  equation?  Suppose  we 
start  with  the  one  point  domain  To  =  I  as  the  first  approximation  to  the  desired  solution.  Taking 
the  proof  of  the  Fixed  Point  Theorem  as  our  guide,  we  build  the  domain  T\  =  To  4-  To  =  I  +  I  as  the 
second  approximation.  Now,  there  is  a  unique  embedding  eo  :  To  — » -  T\  so  this  gives  a  precise  sense 
in  which  To  approximates  T\.  The  next  approximation  to  our  solution  is  the  domain  T-i  =  Tj  +  T\ 
and  again  there  is  an  embedding  e\  =  eo  +  eo  :  T\  — *  Tj.  If  we  continue  along  this  path  we  build  a 
sequence 

To  e0  ^  €7  ^ 

of  approximations  to  the  full  simple  binary  tree.  To  get  a  domain,  we  must  add  limits  for  each  of 
the  branches.  The  resulting  domain  (i.e.  the  full  simple  binary  tree  with  the  limit  points  added) 
is,  indeed,  a  “solution”  of  T  3  T  +  T.  This  is  all  very  informal,  however;  how  are  we  to  make  this 
idea  mathematically  precise  and,  at  the  same  time,  sufficiently  general? 


1.7.1  Solving  domain  equations  with  closures. 

In  this  section  we  discuss  a  technique  for  solving  recursive  domain  equations  by  relating  domains 
to  functions  by  the  “image”  map  (im)  and  then  using  the  ideas  of  the  previous  section  to  solve 
equations.  There  are  two  (closely  related)  ways  of  doing  this  which  we  will  illustrate.  The  first  of 
these  is  based  on  the  following  concept: 

Definition:  Let  D  and  E  be  cpo’s.  A  continuous  function  r  :  D  — ►  E  is  a  closure  if  there  is  a 
continuous  function  s  :  E  —  D  such  that  r  0  3  =  id  and  s  o  r  □  id.  | 

By  analogy  with  the  notion  of  a  finitary  projection,  we  will  say  that  a  function  r  :  D  —  D  is  a 
finitary  closure  if  r  o  r  =  r  □  id  and  im(r)  is  a  domain.  In  the  event  that  D  is  a  domain,  the 
requirement  that  im(r)  be  a  domain  is  unnecessary  because  we  have  the  following: 

Lemma  19  If  D  is  a  domain  and  r  :  D  —>  D  satisfies  the  equation  r  o  r  =  r  □  id,  then  im(r)  is  a 
domain.  | 

The  Lemma  is  proved  by  showing  that  (r(i)  |  x  6  K(D)}  forms  a  basis  for  im(r).  We  will  say  that 
a  domain  E  is  a  closure  of  D  if  it  is  isomorphic  to  im(r)  for  some  finitary  closure  r  on  D.  We  let 
Fc (D)  be  the  poset  of  finitary  closures  r  :  D  — *  D. 

Lemma  20  If  D  is  a  domain,  then  Fc (D)  is  a  cpo.  | 

Definition:  Let  us  say  that  an  operator  F  on  cpo’s  is  representable  over  a  cpo  V  if  and  only  if 
there  is  a  continuous  function  Rp  which  completes  the  following  diagram  (up  to  isomorphism): 


Cpo’s 

im 

Fc  (U) 


Cpo’s 


Rf 


im 


—  Fc  (U) 


i.e.  im(i?F(r))  2  F(im(r))  for  every  closure  r.  | 

This  idea  extends  to  multiary  operators  as  well.  For  example,  the  function  space  operator  •  — *•  •  is 
representable  over  a  cpo  U  if  there  is  a  continuous  function 

R  :  Fc (U)  x  Fc(U)  ->  Fc (U) 


such  that,  for  any  r,s  £  Fc(F), 

im(i2(r,  s))  £  im(r)  — ►  im(s) 

A  operator  (F\, . . . ,  F„)  is  defined  to  be  representable  if  each  of  the  operators  F,  is.  Note  that  a 
composition  of  representable  operators  is  representable. 

Theorem  21  If  an  operator  F  is  representable  over  a  cpo  U,  then  there  is  a  domain  D  such  that 
D  £  F(D). 

Proof:  Suppose  Rp  represents  F.  By  the  Fixed  Point  Theorem,  there  is  an  r  £  Fc (U)  such  that 
r  =  i2f(r).  Thus  im(r)  =  inr^-Rf^r))  £  F(im(r))  so  im(r)  is  the  desired  domain.  | 

Now  we  know  how  to  solve  domain  equations.  For  example,  to  solve  T  =  T  +  T  we  need  to  find 
a  domain  U  and  continuous  function  f  :  U  — *  U  which  represents  the  operator  F(. Y)  =  .Y  +  .Y. 
But  we  are  still  left  with  the  problem  of  finding  a  domain  over  which  such  operations  may  be 
represented!  The  next  step  is  to  look  at  a  simple  structure  which  can  be  used  to  represent  several 
of  the  operations  in  which  we  are  interested. 

Given  sets  5  and  T,  let  Ts  be  the  set  of  (all)  functions  from  5  into  T.  If  T  is  a  cpo,  then  Ts 
is  also  a  cpo  under  the  pointwise  ordering.  Now,  it  is  not  hard  to  see  that  the  domain  equation 
X  £  X  x  lT  (where  lT  is  the  two  point  lattice)  has,  as  one  of  its  solutions,  the  cpo  (lT)^.  In 
fact,  this  cpo  is  isomorphic  to  the  algebraic  cpo  FN  of  subsets  of  N  which  we  discussed  in  the  first 
section.  It  is  particularly  interesting  because  of  the  following: 

Theorem  22  For  any  (countably  based)  algebraic  lattice  L,  there  is  a  closure  r  :  FN  — ►  L. 

Proof:  Let  lo,l\,h, ...  be  an  enumeration  of  the  basis  of  L.  Given  S  C  N,  let  r(5)  =  (J{/n  |  n  £  5}. 
If  f  £  X,  let  s(l)  =  {n  |  /n  E  /}•  We  leave  for  the  reader  the  (easy)  demonstration  that  r,s  are 
continuous  with  r  0  s  =  id  and  s  0  r  □  id.  | 
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Structures  such  as  PN  are  often  referred  to  as  universal  domains  because  they  have  a  rich 
collection  of  domains  as  retracts.  In  the  remainder  of  this  section  we  will  discuss  two  more  similar 
constructions  and  show  how  they  may  be  used  to  provide  representations  for  operators. 

Unfortunately,  there  is  no  representation  for  the  operator  F(X)  =  X  +  X  over  PN.  However, 
there  are  some  much  more  interesting  operators  which  are  representable  over  PN.  In  particular, 

Lemma  23  The  function  space  operator  is  representable  over  PN. 

Proof:  Consider  the  algebraic  lattice  of  functions  PN  — *  PN.  By  Theorem  22,  we  know  that  there 
are  continuous  functions 

:PN  -  (PN  -  PN) 

:  (PN  —  PN)  —  PN 

such  that  o  4r_  =  id  and  o  □  id.  Now,  suppose  r,s  €  Fc(PN)  (that  is,  r  o  r  =  r  □  id 
and  s  o  s  =  s  □  id).  Given  a  continuous  function  /  :  PN  — *  PN,  let  0(s,  r)(/)  =  so  f  or  and  define 

J2_(r,  s)  =  ’5—  o  0(s,  r)  o 

To  see  that  this  function  is  a  finitary  closure,  we  take  x  €  PN  and  compute 

(JU(r,s)  o  R^(r,s))(x) 

=  (<f  _  o  0(s,  r)  o  $_,)($_(s  o  ($_(x))  o  r) 

=  (¥_  o  0(s,r)  o  o  ^_)(s  o  ($_(x))  o  r) 

=  ($_  o  0(s,  r))(s  o  ($_(x))  o  r) 

=  $_((s  o  s)  o  ($_(x))  o  (r  o  r)) 

=  ^_(s  o  ($_(x))  o  r) 

=  R-.(r,s)(x) 

and 

R—(r,s)(x)  =  ¥_(s  o  ($_(x))  o  r)  □  ^_($_(z))  □  x. 

Thus  we  have  defined  a  function, 

:  Fc(PN)  x  Fc(PN)  -  Fc(PN) 

which  we  now  demonstrate  to  be  a  representation  of  the  function  space  operator. 

Given  r,s  6  Fc(PN),  we  must  show  that  there  is  an  isomorphism 

im( R(r,s))  Z  im(r)  — ►  im(s) 

for  each  r,s  6  Fc(PN).  Now,  there  is  sun  evident  isomorphism  between  continuous  functions 
/  :  im(r)  — »  im(s)  and  continuous  functions  g  :  PN  — *  PN  such  that  g  =  s  o  g  o  r.  We  claim  that 
cuts  down  to  an  isomorphism  between  such  functions  and  the  sets  in  the  image  of  /2_(r.s). 
Since  o  ^ _  =  id,  we  need  only  show  that  (’5r_  o  $_)(x)  =  x  for  each  x  =  f?_(r,  s)(x).  But  if 

x  =  'P_(3  o  ($_(x))  o  r) 
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then 


o  $_)(x)  =  ($-o$^o$_)(io($4*))or) 

=  't,_(s  o  ($_(x))  o  r) 

=  x 

Hence  im(.ff_(r,  s))  5£  im(r)  — *  im(s)  and  we  may  conclude  that  represents  — *■  over  TN.  | 

A  similar  construction  can  be  carried  out  for  the  product  operator.  Suppose 

$x  :7>N  —  (PN  X  'PN) 

$x  :(PN  x7>N)^PN 

such  that  <&x  o  $x  =  id  and  'H,x  o  $x  □  id.  For  r,s  €  Fp('PN)  define 

flx(r,s)  =  ¥x  o(r  x  a)o$x 

We  leave  for  the  reader  the  demonstration  that  this  makes  sense  and  Rx  represents  the  product 
operator. 

Suppose  that  L  is  an  algebraic  lattice.  Then  there  are  continuous  functions 

:7>N  —  VH 

*L  :VN  ->  VU 

such  that  o  9 l  =  id  and  Vt,  o  $£  □  id.  Then  the  function 

Rl{t,s )  s  Vl  °$L 

represents  the  constant  operator  X  i->  L  because  im('$£,  o  $/,)  S  L.  A  similar  argument  can  be 
used  to  show  that  a  constant  operator  X  >->  D  is  representable  over  a  domain  U  if  and  only  if  D  is 
a  closure  of  U. 

1.7.2  Modelling  the  untyped  A-calculus. 

It  is  tempting  to  try  to  solve  the  domain  equation  D  3J  D  —  D  by  the  methods  just  discussed. 
Unfortunately,  the  equation  I  S  I  — *■  I  (corresponding  to  the  fact  that  on  a  one-point  set  there  is 
only  one  possible  self-map)  shows  that  there  is  no  guarantee  that  the  result  will  be  at  all  interesting. 
There  has  to  be  a  way  to  build  in  some  nontrival  structure  that  is  not  wiped  out  by  the  fixed-point 
process.  Methods  are  described  in  [Sco76a,  Sco80a],  but  the  following,  from  [Sco76b,  Sco80b],  is 
more  direct  and  more  general. 

Lemma  24  Let  U  be  a  non-trivial  cpo.  If  the  product  and  function  space  operators  can  be  repre¬ 
sented  over  U ,  then  there  are  non-trivial  domains  D  and  E  such  that  E  3  E  x  E  and  D  D  —  E , 

Proof:  We  can  represent  F(X)  =  U  x  X  x  X  over  U,  so  there  is  a  closure  A  of  U  such  that 
AZUxAxA.  Thus  U  x  A  S  U  x  (U  x  A  x  A)  2  (17  x  A)  x  {U  x  A).  So  E  =  U  x  .4  is  non-trivial 
and  E  —  E  x  E .  Now,  E  is  a  closure  of  U  so  G(X)  =  X  —*  E  is  representable  over  U .  Hence  there 
is  a  cpo  D  =  D  — *  E.  This  cpo  is  non-trivial  because  E  is.  | 
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Theorem  25  If  U  is  a  non-trivial  domain  which  represents  products  and  function  spaces,  then 
there  is  a  non-trivial  domain  D  such  that  DSJ)xD2D-*i3  and  D  is  the  image  of  a  closure 
on  U . 

Proof:  Let  D  and  E  be  the  domains  given  by  Lemma  24.  Then 

DxD*(D-+E)x(D-+E)*D^(ExE)*D-+E*D 

and 

D-*DZD-+(D->E)*(DxD)-~E^D-~E*D.  | 

We  note,  in  fact,  that  D  will  have  PN  itself  represented  by  a  closure  on  U .  Hence,  to  get  a 
non-trivial  solution  for  DSD-+fl“DxD,  take  U  in  the  theorem  to  be  PN.  What  good  is 
such  a  domain?  The  answer  is  that  a  D  satisfying  these  isomorphisms  is  a  model  for  a  very  strong 
A-calculus.  If  we  expand  the  syntax  of  A-calculus  given  in  Section  5.3  of  the  chapter  by  Mosses  to 
allow  pairings,  we  would  have: 

E  ::=  (Ax.  E )  |  E\{E^)  \  x  |  pair  |  fst  |  snd 

Now,  Mosses  points  out  that  under  the  semantic  function  he  defines,  many  different  expressions 
are  mapped  into  the  same  values.  We  can  say  that  the  model  satisfies  certain  equations.  In 
particular,  under  the  isomorphisms  obtained  in  our  theorems  above,  the  following  equations  will 
be  satisfied: 

1.  (Ax.  E)  =  ( Xy .  [ylx]E)  (provided  y  is  not  free  in  E) 

2.  (Ax.  E){E')  =  [E'/x]E 

3.  (Ax.  E{x))  =  E  (provided  x  is  not  free  in  E) 

4.  fst(pair(£)(£'))  =  E 

5.  snd(pair(£,)(£1'))  =  E' 

6.  pair(fst(£))(snd(.£))  =  E 

In  these  equations,  the  third  and  sixth  especially  emphasize  the  isomorphisms  D  =  D  — *•  D  and 
D  =  D  x  D.  There  are  models  where  D  — *  D  is  represented  by  a  closure  on  D  (as  is  D  x  D) 
but  where  this  is  not  an  isomorphism.  It  follows  that  the  special  equations  are  independent  of  the 
others. 

In  [Rev87]  the  question  is  brought  up  whether  we  can  add  to  the  above  equations  one  relating 
functional  abstraction  with  pairing.  In  particular,  the  following  would  be  interesting: 

pair(x)(y)  =  (Ax.  pair(x(z))(y(x))). 

This  equation  identifies  the  primitive  pairing  with  what  could  be  called  pointwise  pairing.  This 
equation  is  independent  from  the  others,  but  a  model  for  it  can  be  obtained  from  the  first  model  by 
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introducing  a  new  pairing  and  application  operation  ♦hat  does  things  pointwise  in  a  suitable  sense. 
There  must  be  many  other  kinds  of  models  that  relate  the  functional  structure  to  other  constructs 
as  well. 

Suppose  we  have  domains  that  satisfy  just  the  six  equations.  Then  from  the  primitive  operations 
given,  many  others  can  be  defined.  The  operation  of  A-abstraction  is,  to  be  sure,  a  variable-binding 
operator  (somewhat  like  a  quantifier),  but  the  others  are  algebraic  in  nature.  As  stated,  application 
is  a  binary  operation,  and  pair,  fst  and  snd  are  constants.  But  we  can  define  binary,  ternary,  and 
unary  operations  such  as:  pair(x)(y),  pair(x)(pair(y)(x)),  fst(x),  snd(y),  pair(snd(x))(fst(x)),  and 
many,  many  more.  In  other  words,  the  domain  D  will  become  a  model  of  many  kinds  of  algebras. 

In  general,  an  algebra  is  a  set  together  with  several  operations  defined  on  it,  taking  values  in  the 
same  set.  The  simplest  situation  is  to  consider  finitary  operations  (i.e.,  operations  taking  a  fixed 
finite  number  of  arguments).  When  giving  an  algebra,  the  sequence  of  arities  of  the  fundamental 
operations  is  called  the  signature  of  the  algebra.  Thus,  a  ring  is  often  given  with  just  two  binary 
operations  ( addition  and  multiplication)  making  a  signature  (2,2).  Now,  subtraction  is  definable  in 
first-order  logic  from  addition,  but  the  definition  is  not  equational.  Therefore,  it  may  be  better  to 
consider  a  ring  as  an  algebra  of  signature  (2,2,2)  with  subtraction  being  taken  as  primitive.  Of, 
course  it  is  enough  to  have  the  minus  operation,  which  is  unary.  So,  a  signature  (2,1,2)  is  also 
popular.  Strictly  speaking,  however,  different  signatures  correspond  to  algebras  of  different  types. 
Not  every  algebra  of  signature  (2,2,2)  is  “equivalent”  to  one  of  signature  (2,1,2);  rings  as  algebras 
have  very  special  properties. 

By  a  continuous  algebra  we  mean  a  domain  with  various  continuous  operations  singled  out.  In 
particular,  our  A-calculus  model  can  be  considered  as  a  continuous  algebra  of  signature  (2, 0,0.0. 0,0). 
The  binary  operation  is  the  operation  of  functional  application.  Here,  0  indicates  a  0-ary  operation, 
which  is  just  a  constant.  We  already  know  the  constants  pair,  fst,  snd.  The  other  two  popular 
constants  from  the  literature  on  A-calculus  are  called  5  and  K.  In  terms  of  A-abstraction  they  can 
be  defined  as  follows: 

S  =  (Ax.  (Ay.  (Ax.  x(x)(y(z))))) 

K  =  (Ax.  (Ay.  x)) 

They  enjoy  many,  many  equations  in  the  algebra  (see,  for  example,  [Bar84])  and,  in  fact,  any 
equation  involving  the  A-operator  can  be  rewritten  purely  algebraically  in  terms  of  5  and  I\  and 
application. 

We  will  call  an  expression  in  the  notation  of  applicative  algebra  which  has  no  variables  a 
combination.  Any  combination  F  defines  an  n-ary  operation: 

f’(x1)(x2)...(xn). 

What  we  have  been  remarking  is  that  the  algebras  so  obtained  from  combinations  can  be  verv 
rich.  In  a  series  of  papers  [Eng81,  Eng]  Engeler  discussed  just  how  rich  these  algebras  can  be.  A 
representative  result,  following  Engeler,  will  be  exhibited  here. 

Theorem  28  Given  a  signature  (si,s2, . . .  ,s„),  there  are  combinations  Fj,  F2, . . .  ,Fn  defining  op¬ 
erations  on  D  of  these  arities  such  that  whenever  a  continuous  algebra  of  this  signature  is  given 
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on  a  domain  A  that  is  a  retract  of  D,  then  A  can  be  made  isomorphic  to  a  subalgebra  of  this  fixed 
algebra  structure  on  D. 

Proof:  If  A  is  a  retract  of  D ,  then  A  can  be  regarded  as  a  subset  of  D,  and  all  the  continuous 
operations  on  A  ran  be  naturally  eYteuded  to  continuous  operations  on  D  of  the  same  arities.  (This 
does  not  solve  the  problem,  since  the  operations  on  D  depend  on  the  choice  of  A.  That  is  to  say,  at 
the  start  A  is  a  subalgebra  of  the  wrong  algebra  on  D.)  We  can  call  these  operations  01,02,. . .  ,on. 

We  are  going  to  define  the  representation  of  A  as  a  subalgebra  of  D  by  means  of  a  continuous 
function  p  :  A  —*  D  defined  by  means  of  a  fixed-point  equation: 

p(a)  =  pair(a) 

(pair(Ax2  •  •  •  Ax„ .  p(<?i(a, fst(x2),  •  •  •  ,fst(x„ )))) 

(pair(Ax2  •  •  •  AxJ2  •  fst(x2 fst(xJ2  )))) 

(paif(Ax2  . . .  AxJn.  p(on(a,fst(x2),  •  •  •  ,^t(xJn)))) 

(*))■••) 

In  this  way,  we  build  into  p  the  elements  from  A  and  the  operations  as  well.  The  question  is  how 
to  read  off  the  coded  information. 

Consider  the  following  combinations: 

F\  —  Ax.  fst(snd(x)) 

F2  =  Ax.  fst(snd(snd(x))) 

Fn  =  Ax.  fst(snd(snd(- • -snd(x)))), 

which  have  to  be  rewritten  in  terms  of  5,  K,  fst,  and  snd.  We  then  calculate  that 

Ffip{a^)){p(a2))  •  •  •  (p(ati))  =  p(oi(ai,a2, . . .  a,,)). 

This  means  if  we  consider  the  algebra  (D,  F\,  F2, . . . ,  Fn),  then  we  can  find  by  means  of  the 
definition  of  p  any  algebra  (A,oi,02,...,on),  isomorphic  to  a  subalgebra  of  the  first  algebra.  | 

1.7.3  Solving  domain  equations  with  projections. 

As  we  mentioned  earlier,  one  slightly  bothersome  drawback  to  "PN  as  a  domain  for  solving  recursive 
domain  equations  is  the  fact  that  it  cannot  represent  the  sum  operator  +.  One  might  try  to 
overcome  this  problem  by  using  the  operator  (  •  +  •  )T  as  a  substitute  since  this  is  representable 
over  PN.  However,  the  added  top  element  seems  unmotivated  and  gets  in  the  way.  It  is  probably 
possible  to  find  a  cpo  which  will  represent  the  operators  x ,  — ►,  +.  However,  for  the  sake  of  variety, 
we  will  discuss  a  slightly  different  method  for  solving  domain  equations.  Let  us  say  that  an  operator 
F  on  cpo’s  is  p- representable  over  a  cpo  U  if  and  only  if  there  is  a  continuous  function  Rp  which 
completes  the  following  diagram  (up  to  isomorphism): 
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Since  there  will  be  no  chance  of  confusion,  let  us  just  use  the  term  “representable”  for  “p- 
representable”  for  the  remainder  of  this  section.  Since  Fp(?7)  is  a  cpo  we  can  solve  domain  equations 
in  the  same  way  we  did  before  provided  we  can  find  domains  over  which  the  necessary  operators 
can  be  represented. 

The  construction  of  a  suitable  domain  is  somewhat  more  involved  than  was  the  case  for  VN. 
We  begin  by  describing  the  basis  of  a  domain  U .  Let  S  be  the  set  of  rational  numbers  of  the  form 
n/2m  where  0  <  n  <  2m  and  0  <  m.  As  the  basis  Uo  of  our  domain  we  take  finite  (non-empty) 
unions  of  half  open  intervals  [r,  t)  =  {s  6  5  |  r  <  3  <  £}.  A  typical  element  would  look  like 


[  1--1 - 1--  'I  I  - . I  ) 


We  order  these  sets  by  superset  so  that  the  interval  [0, 1)  is  the  least  element.  There  is  no  top 
element  under  this  ordering.  If  we  adjoin  the  emptyset,  say  B  —  Uo  U  {0},  then  we  get  a  Boolean 
algebra.  (Note  that  the  complement  of  a  finite  union  of  intervals  is  again  one  such — unless  it  is 
empty.)  In  particular,  any  interval  contains  a  proper  sub-interval  so,  as. a  Boolean  algebra,  B 
is  atomless.  But  B  is  countable,  and — up  to  isomorphism — the  only  countable  aimless  Boolean 
algebra  is  the  free  one  on  countably  many  generators.  But  this  Boolean  algebra  has  the  property 
that  every  countable  Boolean  algebra  is  isomorphic  to  a  subalgebra.  Now,  suppose  .4  is  a  countable 
bounded  complete  poset.  Let  B'  be  the  boolean  algebra  of  subsets  of  A  generated  by  those  subsets 
of  the  form  Ti  =  {y  6  4  |  i  C  y}  and  order  this  collection  by  superset  so  that  0  will  be  its  largest 
element.  The  map  i :  x  »-*.  |  x  is  a  monotone  injection  which  preserves  existing  least  upper  bounds. 
Moreover,  a  subset  u  C  A  is  bounded  just  in  case  Plrgu  T  x is  non-empty.  Now,  if  j  :  B'  —  B  maps 
B'  isomorphically  onto  a  subalgebra  of  B,  then  the  composition  j  o  i  cuts  down  to  an  isomorphism 
between  A  and  a  normal  subposet  A'  <  Uo-  Letting  U  be  the  domain  of  ideals  over  Uo  we  may  now 
conclude  the  following: 

Theorem  27  For  any  bounded  complete  domain  D,  there  is  a  projection 

p  :  U  — *  Z?.  | 

We  can  now  use  this  to  see  that  an  equation  like  X  25  Nx  +  (X  —  X)  has  a  solution.  The  proof 
that  — ►  is  representable  over  U  is  almost  identical  to  the  proof  we  gave  above  that  it  is  representable 
over  VH.  To  get  a  representation  for  +,  take  a  pair  of  continuous  functions 

$+  :  U  -  (U  +  U) 

«+  :  (U  +  U)  —  U 
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such  that  $+  o  $+  =  id  and  $+  o  $+  C  id.  Then  take 

iZ+(r,3)  =  o  (r  +  s)  o  $+. 

Also,  there  is  a  representation  Rftx  for  constant  operator  X  *-*  N^.  Hence  the  operator  X  - 
Nx  +  (X  —*  X)  is  represented  over  U  by  the  function 

p  i-  R+  ( i?N  A  (p) ,  R-  (p,  p) ) . 

We  have,  in  fact,  the  following: 

Lemma  28  The  following  operators  are  representable  over  U;  — *,  o-+,  x,  ®,+,  ©,(-)±-  (•)*»  (•)*• 1 

This  means  that  we  have  solutions  over  the  bounded  complete  domains  for  a  quite  substantial 
class  of  recursive  equations.  More  discussion  of  U  may  be  found  in  [Sco8l],  [Sco82a]  and  [Sco82b]. 

1.7.4  Representing  operators  on  bifinite  domains. 

The  convex  powerdomain  (•)il  cannot  be  representable  over  U  because  it  does  not  preserve  bounded 
completeness.  We  construct  a  domain  over  which  this  operator  can  be  represented  as  follows.  Given 
a  poset  A ,  define  M(A)  to  be  the  of  pairs  (x,u)  £  A  X  V/(A)  such  that  x  C  z  for  every  z  £  u. 
Define  a  pre-ordering  on  M(A)  by  setting  (x,  u)  I-  (y,  u)  if  and  only  if  there  is  a  z  £  u  such  that 
z  C  y.  Now,  given  a  domain  D,  we  define  D+  to  be  the  domain  of  ideals  over  (A/(.4),  I-). 

Theorem  29  If  D  is  bifinite,  then  so  is  D+ .  Moreover,  if  D  =5  D+  and  E  is  any  bifinite  domain, 
then  there  is  a  projection  p  :  D  -*  E.  | 

A  full  proof  of  the  theorem  may  be  found  in  [Gun87].  We  will  attempt  to  offer  some  hint  about 
how  the  desired  fixed  point  is  obtained.  At  the  first  step  we  take  the  domain  I  =  {_L}  containing 
only  the  single  point  X.  At  the  second  step,  l+,  there  are  elements  a  =  (X,{±})  and  b  =  (_L,0) 
with  6  h  a.  At  the  third  step  there  are  five  elements 

(a,  {a}),  (a,  {b}),  (b,{b}),  (6,0),  (a,0) 

which  form  the  partially  ordered  set  l++  pictured  in  Figure  1.4.  Note  that  there  is  another  element 
(a,  {a,  6})  £  M( l+)  but  this  satisfies  (a,  {a})  H  (a,  {a,  6})  and  (a,  {a.  6})  I-  (a,  {a})  so  we  have 
identified  these  elements  in  the  picture.  The  next  step  l+++  has  20  elements  (up  to  equivalence 
in  the  sense  just  mentioned)  and  it  is  also  pictured  in  Figure  1.4.  We  leave  the  task  of  drawing  a 
picture  of  |++++  as  an  exercise  for  the  (zealous)  reader.  It  should  be  noted  that  each  stage  of  the 
construction  is  embedded  in  the  next  one  by  the  map  x  •-*  (x,  {x}).  The  closed  circles  in  the  figure 
are  intended  to  give  a  hint  of  how  this  embedding  looks. 

The  technique  which  we  have  used  to  build  this  domain  can  be  generalized  and  used  for  other 
classes  as  well  [GJ88]. 

We  have  the  following: 
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1+  I++  I+++ 


Figure  1.4:  A  domain  for  representing  operators  on  bifinites. 

Lemma  30  The  following  operators  are  p-representable  over  V:  — ►,  »-♦,  x,  ®,+,  ®.o±,  (•)*. 
(•)k.  (■)*•! 

As  with  most  of  the  other  operators,  to  get  a  representation  for  (-)11,  take  a  pair  of  continuous 
functions 

:  V  -  V* 

:  V*  -  V 

such  that  $||  o  =  id  and  o  4>|,  C  id.  Then 

Rk(p)  =  ( P *)  o 

is  a  representation  for  the  convex  powerdomain  operator. 

We  hope  that  the  reader  has  begun  to  note  a  pattern  in  the  way  operators  are  represented.  Most 
of  the  operators  (x,®, +,  ®,  (-)xi(-)8>  (O11)  may  he  handled  rather  straight- forwardly  using  the 

corresponding  action  of  these  operators  on  functions.  Slightly  more  care  must  be  taken  in  dealing 
with  the  function  space  and  strict  function  space  operators  where  one  must  use  a  function  like  0. 
The  stock  of  operators  that  we  have  defined  in  this  chapter  is  quite  powerful  and  it  can  be  used  for 
a  wide  range  of  denotational  specifications.  However,  the  methods  that  we  have  used  to  show  facts 
such  as  representability  (using  finitary  closures  or  finitary  projections)  will  apply  to  a  very  large 
class  of  operators  which  satisfy  certain  sufficient  conditions. 
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To  understand  this  phenomenon,  one  must  pass  to  a  more  general  theory  in  which  such  operators 
are  a  basic  topic  of  study.  This  is  the  theory  of  categories.  Many  people  find  it  difficult  to  gain 
access  to  the  theory  of  domains  when  it  is  described  with  categorical  terminology.  On  the  other 
hand,  it  is  difficult  to  explain  basic  concepts  of  domain  theory  without  the  extremely  useful  general 
language  of  category  theory.  A  good  exposition  of  the  relevance  of  category  theory  to  the  theory 
of  semantic  domains  may  be  found  in  [SP82]. 

Only  a  small  number  of  categories  of  spaces  having  the  properties  which  we  have  described 
above  are  known  to  exist.  What  are  the  special  traits  that  these  categories  possess?  First  of  all, 
they  have  product  and  function  space  functors  which  satisfy  the  relationship  we  described  at  the 
beginning  of  section  4.  This  property,  known  as  cartesian  closure  is  a  well-known  characteristic 
of  categories  such  as  that  of  sets  and  functions.  But  our  cartesian  closed  categories  have  not  only 
fixed  points  for  (all)  morphlsms  but  fixed  points  for  many  functors  as  well.  It  is  this  latter  feature 
which  makes  them  well  adapted  to  the  task  of  acting  as  classes  of  semantic  domains.  One  additional 
property  which  makes  these  categories  special  is  the  existence  of  domains  for  representing  functors. 

This  is  not  to  say  that  there  are  not  other  categories  which  will  have  the  desired  properties. 
One  particularly  interesting  example  are  the  stable  structures  of  Berry  [Ber78]  which  we  have  not 
had  the  space  to  discuss  here.  Interesting  new  examples  of  such  categories  are  being  uncovered 
by  researchers  at  the  time  of  the  writing  of  this  chapter.  The  reader  will  find  a  few  leads  to 
such  examples  in  the  published  literature  listed  below,  and  we  expect  that  many  quite  different 
approaches  will  be  put  forward  in  future  years. 
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Chapter  2 


Denotational  Semantics. 
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2.1  Introduction 


In  programming  linguistics,  as  in  the  study  of  natural  languages,  “syntax”  is  distinguished  from 
“semantics”.  The  syntax  of  a  programming  language  is  concerned  only  with  the  structure  of 
programs:  whether  programs  are  “legal”;  the  connections  and  relations  between  the  symbols  and 
phrases  that  occur  in  them.  Semantics  deals  with  what  legal  programs  mean:  the  “behaviour” 
they  produce  when  executed  by  computers. 

The  topic  of  this  chapter,  Denotations!  Semantics,  is  a  framework  for  the  formal  description  of 
programming  language  semantics.  The  main  idea  of  Denotational  Semantics  is  that  each  phrase  of 
the  language  described  is  given  a  denotation:  a  mathematical  object  that  represents  the  contribution 
of  the  phrase  to  the  meaning  of  any  complete  program  in  which  it  occurs.  Moreover,  the  denotation 
of  each  phrase  is  determined  just  by  the  denotations  of  its  subphrases. 

Thus  Denotational  Semantics  is  concerned  with  giving  mathematical  models  for  programming 
languages.  Models  are  constructed  from  given  mathematical  entities  (functions,  numbers,  tuples, 
etc.).  This  is  in  contrast  to  the  axiomatic  approach  used  in  other  major  frameworks,  such  as  Hoare 
Logic  [10]  and  Structured  Operational  Semantics  [24]. 

The  primary  aim  of  Denotational  Semantics  is  to  allow  canonical  definitions  of  the  meanings  of 
programs.  A  canonical,  denotational  definition  of  a  programming  language  documents  the  design 
of  the  language.  It  also  establishes  a  standard  for  implementations  of  the  language — ensuring  that 
each  program  gives  essentially  the  same  results  on  all  implementations  that  conform  to  the  standard. 
A  denotational  definition  does  not  specify  the  techniques  to  be  used  in  implementations;  it  may, 
however,  suggest  some,  and  it  has  been  shown  feasible  to  develop  implementations  systematically 
from  specifications  written  using  the  denotational  approach.  Finally,  a  denotational  definition 
provides  a  basis  for  reasoning  about  the  correctness  of  programs — either  directly,  or  by  means  of 
derived  proof  rules  for  correctness  assertions. 

A  further  aim  of  Denotational  Semantics  is  to  promote  insight  regarding  the  concepts  underlying 
programming  languages.  Such  insight  might  help  to  guide  the  design  of  new  (and  perhaps  “better”) 
programming  languages. 

Currently,  most  programming  language  standards  documents  attempt  to  define  semantics  by 
means  of  informal  explanations.  This  is  in  contrast  to  syntax,  where  formal  grammars  are  rou¬ 
tinely  used  in  standards  (in  preference  to  informal  explanations).  However,  experience  has  shown 
that  informal  explanations  of  semantics,  even  when  they  are  carefully  worded,  are  usually  incom¬ 
plete  or  inconsistent  (or  both),  and  open  to  misinterpretation  by  implementors.  They  are  also  an 
inadequate  basis  for  reasoning  about  program  correctness,  and  totally  unsuitable  for  generation 
of  implementations.  These  inherent  defects  of  informal  explanations  do  not  afflict  denotational 
definitions  (except  when  definitions  are  left  unfinished,  or  when  their  formal  status  is  weakened  by 
excessive  use  of  informal  abbreviations  and  conventions). 

This  chapter  has  two  purposes.  The  first  of  these  is  to  explain  the  formalism  used  in  Denota¬ 
tional  Semantics:  abstract  syntax,  semantic  functions,  and  semantic  domains.  Section  2.2  relates 
concrete  syntax  and  abstract  syntax.  Section  2.3  considers  the  nature  of  semantic  functions,  and  ex- 
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plains  the  properties  of  compositionality  and  full  abstractness.  Section  2.4  summarizes  the  concepts 
and  notation  of  semantic  domains,  referring  to  Gunter  and  Scott  [18]  for  a  detailed  presentation  of 
domain  theory. 

The  second  purpose  of  this  chapter  is  to  illustrate  the  major  standard  techniques  that  are 
used  in  denotational  descriptions  of  programming  languages:  environments,  stores,  continuations, 
etc.  Section  2.5  explains  the  relation  between  these  techniques  and  some  fundamental  concepts 
of  programming  languages,  and  uses  the  techniques  to  give  denotational  descriptions  of  many 
conventional  programming  constructs. 

The  Bibliographical  Notes  (Section  2.6)  provide  references  to  some  significant  works  on  Deno¬ 
tational  Semantics. 

The  reader  is  expected  to  be  familiar  with  the  basic  notions  of  discrete  mathematics  (sets, 
functions,  relations,  partial  orders)  and  to  be  prepared  to  meet  a  substantial  amount  of  formal 
notation.  Familiarity  with  programming  languages  is  an  advantage,  but  not  essential. 
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2.2  Syntax 

♦ 

As  mentioned  at  the  beginning,  the  syntax  of  a  programming  language  is  concerned  only  with  the 
structure  of  programs:  which  programs  are  “legal”;  what  are  the  connections  and  relations  between 
the  symbols  and  phrases  that  occur  in  them. 

There  are  several  kinds  of  syntax,  which  we  distinguish  below.  (Readers  who  are  familiar 
with  the  distinction  between  “concrete  syntax”  and  “abstract  syntax”  may  prefer  to  skip  to  Sec¬ 
tion  2.2.3.) 

2.2.1  Concrete  syntax 

Concrete  Syntax  treats  a  language  as  a  set  of  strings  over  an  alphabet  of  symbols. 

Concrete  syntax  is  usually  specified  by  a  grammar  that  gives  “productions”  for  generating 
strings  of  symbols,  using  auxiliary  “nonterminal”  symbols.  So-called  “regular”  grammars  are  inad¬ 
equate  for  specifying  syntax  of  programming  languages:  “context-free”  grammars  are  required,  at 
least. 

Definition:  A  context-free  grammar  G  is  a  quadruple  (TV,  T,  P,  so)  where  TV  is  a  finite  set  of 
nonterminal  symbols,  T  is  a  finite  set  of  terminal  symbols  (disjoint  from  TV ),  P  C  N  X  (TV  U  T)“  is 
a  finite  set  of  productions,  and  sQ  €  TV  is  the  start  symbol. 

(In  this  section,  Xm  is  the  set  of  strings  over  X,  for  any  set  X;  the  empty  string  is  indicated  by 
A,  and  string  concatenation  by  juxtaposition.  The  notation  Xm  is  given  a  different  interpretation 
when  A"  is  a  semantic  domain,  from  Section  2.4  onwards.) 

It  is  common  practice  to  distinguish  a  lexical  level  and  a  phrase  level  in  concrete  syntax.  The 
terminal  symbols  in  the  grammar  specifying  the  lexical  level  are  single  characters;  those  in  the 
phrase-level  grammar  are  the  nonterminal  symbols  of  the  lexical  grammar.  Here,  let  us  ignore  the 
distinction  between  the  lexical  and  phrase  levels,  for  simplicity. 

When  presenting  a  grammar,  it  is  enough  to  list  the  productions:  the  sets  of  nonterminal  and 
terminal  symbols  are  implicit,  the  start  symbol  is  determined  by  the  first  production.  We  write 
a  production  (a,(x i...xn))  as  a  ::=  xi...xn.  We  may  also  group  several  productions  for  the 
same  nonterminal,  separating  the  alternative  strings  on  the  right-hand  side  by  ‘|\  (This  notation 
for  grammars  is  essentially  the  same  as  so-called  BNF .)  For  later  use,  a  mnemonic  name  called  a 
phrase  sort  is  associated  with  each  nonterminal  symbol  (we  write  the  phrase  sort  in  parentheses) 
and  occurrences  of  nonterminal  symbols  in  right-hand  sides  of  productions  may  be  distinguished 
by  subscripts. 

An  example  of  a  grammar  for  the  concrete  syntax  of  a  simple  language  of  expressions  is  given 
in  Table  2.1.  (The  productions  for  identifiers  are  omitted,  as  they  are  of  no  interest.) 

We  could  define  the  language  of  strings  generated  by  a  context-free  grammar  in  terms  of  “deriva¬ 
tion  steps”.  For  our  purposes  here,  it  is  more  convenient  to  go  straight  to  the  notion  of  “derivation 
trees”,  in  which  the  order  of  derivation  steps  is  ignored. 
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(Expression) 

E  ::=  T 

E*  T  |  E  -  T 

(Term) 

T  ::=  F 

T  *  F 

(Factor) 

F  I  1 

(  E  ) 

(Identifier) 

I  ::=  unspecified 

Table  2.1:  A  grammar  for  concrete  syntax 


Definition:  Let  X  be  a  set  (of  labels).  An  L-labeled  tree  t  is  a  pair  (l,(t\  ■•■tn)),  where  /  £  X, 
n  >  0,  and  t\  . . .  tn  is  a  string  of  X-labeled  trees.  We  say  that  t  has  label  l  and  branches  t\, . . . ,  tn. 

Let  Treei  be  the  set  of  finite  X-labeled  trees;  this  is  the  least  set  that  is  closed  under  construction 
of  X-labeled  trees. 

(Of  course,  other  representations  of  trees  are  possible,  e.g.,  as  partial  functions  from  “occur¬ 
rences”  to  labels.) 


Definition:  For  any  t  £  Tree*,,  frontier(t)  £  X*  is  defined  (inductively)  by 


frontier^, (ti  •••*„)) 


f  /,  if  n  =  0; 

\  frontier(/x)  •••  frontier(tn),  if  n  >  0. 


Definition:  A  derivation  tree  according  to  a  grammar  G  =  ( N,T,P,so )  is  a  finite  (.V  uTl-labeled 
tree  with  label  so,  such  that  if  a  node  labeled  a  has  branches  labeled  ii,...,xn,  n  >  0,  then 

(a,(*i  ••■*„))  €  P. 

The  set  of  all  derivation  trees  according  to  G  is  denoted  by  Treec- 


For  notational  convenience  we  identify  the  tree  (/,  (A))  with  l.  This  allows  us  to  write,  e.g., 
(a,  (zi  tx 2))  to  form  a  derivation  tree,  where  t  is  a  tree  and  xj,  X2  are  terminal  symbols.  Figure  2.1 
depicts  a  derivation  tree  according  to  the  grammar  of  Table  2.1. 

Now  that  we  know  what  derivation  trees  are,  let  us  use  them  to  define  the  languages  generated 
by  grammars: 


Definition:  The  language  of  strings  C(G)  C  T*  generated  by  a  grammar  G  =  (jV,  T,  P,  so)  is  given 
by 

C{G)  —  {w  £  Tm  |  3t  £  Treec  :  w  =  frontier(t)}. 

If  any  string  in  £(G)  has  more  than  one  derivation  tree,  then  G  is  said  to  be  ambiguous. 
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Whereas  ambiguity  seems  to  be  an  inescapable  feature  of  natural  languages,  it  is  to  be  avoided 
in  programming  languages.  For  example,  there  should  be  no  vagueness  about  whether  ‘a*b+c'  is  to 
be  read  as  ‘a*(b+c)’  or  as  ‘(a*b)+c\  since  they  should  evaluate  to  different  results,  in  general.  (Of 
course  grouping  may  not  matter  in  some  cases,  such  as  ‘a+b+c’.)  Moreover,  the  efficient  generation 
of  language  parsers  from  grammars  requires  special  kinds  of  unambiguous  grammars,  e.g..  satisfying 
the  so-called  LALR(l)  condition. 

Unfortunately,  unambiguous  grammars  tend  to  be  substantially  more  complex  than  ambiguous 
grammars  for  the  same  language,  and  they  often  require  nonterminal  symbols  and  productions  that 
have  no  relevance  to  the  essential  phrase  structure  of  the  language  concerned.  For  the  purposes  of 
semantics,  the  phrase  structure  of  languages  should  be  as  simple  as  possible,  devoid  of  semantically- 
irrelevant  details.  Yet  there  should  be  no  ambiguity  in  the  structure  of  phrases!  Thus  we  are  led 
to  use  ambiguous  grammars,  but  to  interpret  them  in  such  a  way  that  the  specified  syntactic 
entities  themselves  can  be  unambiguously  decomposed.  Such  a  framework  is  provided  by  so-called 
“abstract”  syntax. 

2.2.2  Abstract  syntax 

Abstract  syntax  treats  a  language  as  a  set  of  trees.  The  important  thing  about  trees  is  that, 
unlike  strings,  their  compositional  structure  is  inherently  unambiguous:  there  is  only  one  way  of 
constructing  a  particular  tree  out  of  its  (immediate)  sub-trees. 

It  is  convenient  to  use  derivation  trees  to  represent  abstract  syntax.  Abstract  syntax  is  specified 
using  the  same  kind  of  (context-free)  grammar  that  is  used  for  concrete  syntax — but  now  there  is  no 
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worry  about  ambiguity.  An  example  of  a  grammar  for  abstract  syntax  is  given  in  Table  2.2.  It  gives 
an  appropriate  abstract  syntax  for  the  language  generated  by  the  grammar  of  Table  2.1.  Notice 
that  the  nonterminal  symbols  T  and  F,  together  with  the  terminal  symbols  ‘(’  and  ‘)\  are  not 
present  in  the  abstract  syntax:  they  were  only  for  grouping  in  concrete  syntax.  Also,  the  various 
concrete  expressions  involving  operators  are  collapsed  into  a  single  form  of  abstract  expression — at 
the  expense  of  introducing  the  nonterminal  symbol  O.  Figure  2.2  shows  a  derivation  tree  according 
to  the  grammar  of  Table  2.2. 

(Expression) 

E  ::=  I  \  Ei  O  Eh 

(Operator) 


(Identifier) 

I  ::=  unspecified 

Table  2.2:  A  grammar  for  abstract  syntax 


Definition:  The  abstract  syntax  defined  by  a  grammar  G  is  Tree^,  the  set  of  derivation  trees 
according  to  G. 


The  phrase  sorts  associated  with  nonterminal  symbols  in  our  grammars  (such  as  Expression, 
Identifier)  identify  corresponding  sets  of  derivation  trees  (note  that  such  trees  generally  occur 
only  as  branches  of  trees  in  Treec)- 

Abstract  syntax  may  be  characterized  algebraically,  using  the  notion  of  a  “signature”,  as  follows. 

Definition:  Let  5  be  a  set  (of  sorts).  An  S-sorted  signature  E  is  a  family  of  sets  {Eu;,i}u/€S*,.»€S 
(of  operators). 

A  E -algebra  A  consists  of  a  family  {A,},g5  of  sets  (called  earners)  and  for  each  operator 
/  €  a  total  function  fA  :  A„  x  •  •  •  x  A,„  —  A,. 
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Definition:  A  E-homomorphism  h  :  A  — ►  B  (where  A  and  B  are  E-algebras)  is  a  family  {hj}aes 
of  (total)  functions  h,  :  .4,  — ►  B ,  such  that  for  each  f  €  E„...3niJ  and  a,  e  ASi 

fB(h-ai  (al),  •  •  •  *^»n(an))  —  hs{/A(a  1»-  •  •  »an))* 

The  composition  h'  o  h  of  E-homomorphisms  h  \  A  -*  B,  h'  :  B  -*  C  is  the  family  of  func¬ 
tions  {h'a  o  h,}j€s.  The  identity  E-homomorphism  id^  :  A  — *  A  is  the  family  of  identity  functions 
{id,4,}j€S-  The  E-algebras  A,  Base  said  to  be  isomorphic  when  there  exist  E-homomorphisms 
h  :  A  — *•  B,  h' :  B  —*  A  such  that  h'  o  h  =  id^  and  h  o  h'  =  i 6g. 

The  key  concept  is  that  of  “initiality”: 

Definition:  A  E-algebra  /  is  initial  in  a  class  C  of  E-algebras  iff  there  is  a  unique  E-homomorphism 
from  I  to  each  algebra  in  C. 

Proposition  31  If  I  and  J  are  both  initial  in  a  class  C  of  E-algebras,  then  I  and  J  are  isomorphic. 

Proof:  Let  h  :  I  -*  J ,  h'  :  J  —*  I  be  the  unique  homomorphisms  given  by  the  initiality  of  I,  re¬ 
spectively  J.  Now  h'  o  h  and  id/  are  both  homomorphisms  from  /  to  itself;  by  the  initiality  of  I 
they  must  be  equal.  Similarly,  h  o  h'  =  idj] 

For  each  grammar  G  we  define  a  corresponding  signature  Eg,  as  follows: 

Definition:  Let  G  =  ( N,T,P,s0 ).  Then  Eg  is  the  IV-sorted  signature  with 

—  { P  €  P  |  P  =  (s,  (tiOSl  •  •  ■  SnUn))i  1*0,  •  •  •  » un  €  T  } 

for  each  (si . . .  sn)  6  N *  and  s  €  N. 

By  the  way,  not  all  signatures  can  be  made  into  context-free  grammars:  a  signature  may  have  an 
infinite  number  of  sorts  and  operators.  Notice  also  that  a  signature  does  not  have  a  distinguished 
“start  sort”. 

Now  Treec  can  be  made  into  a  Ec-algebra,  which  we  denote  by  A(G),  as  follows.  Take  the 
carriers  A(G),  to  be  A(N,T,  P,s)  for  each  s  £  N.  (In  practice  it  is  convenient  to  refer  to  these 
sets  by  mnemonic  names,  associated  with  nonterminal  symbols  when  grammars  axe  specified.)  For 
each  p  6  Eg, 4,.  ..4„,4  with  p  =  (s,(u0si  . . .  snun)),  where  uj, . . .  ,un  6  T‘,  define  a  function 

Pa(G)  ■  A(G)tl  x  •••  x  A(G)a„  -  A(G), 

by  letting  for  all  t,  £  A(G)a , ,  for  i  =  1, . . . ,  n, 

PA(G)(t\ ,  •  •  •  >  )  —  (  ^ ,  (  Hot  i  . . .  tnUn  )). 

Proposition  32  A(G)  is  initial  in  the  class  of  all  Ea-algebras. 

Proof:  Let  A  be  any  Ec-algebra.  Define  { h ,  :  A(G)a  —  A,}j€S  inductively,  as  follows.  If  t  = 
(s,  (uq  t\  . .  .tntin))  with  each  u,-  €  T*  and  each  t,-  €  A(G)ai ,  and  p  =  (s,  (uqSi  . . .  sn  un)),  then 
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^a(0  —  Pa(^si(^i)»  •  •  •  i  ^Jn(^n))' 

As  each  t  €  ^(G)#  is  uniquely  decomposable  as  (s,  (tio*i  •  •  •  *n«n))»  the  ha  are  well-defined  (and  they 
are  total  since  derivation  trees  axe  finite).  Moreover  it  can  be  seen  that  this  definition  is  forced  by 
the  homomorphic  property,  so  {h4}4€s  is  the  unique  homomorphism  from  A(G)  to  A.  Hence  A{G) 
is  initial  in  the  class  of  all  £<3-algebrasJ 

Denotations!  Semantics  defines  the  semantics  of  a  programming  language  on  the  basis  of  its 
abstract  syntax.  The  semantics  of  some  concrete  syntax  may  be  obtained  as  well:  by  giving  a 
function  that  maps  concrete  syntax  into  abstract  syntax.  Assuming  that  the  concrete  grammar  is 
unambiguous,  it  is  enough  to  map  concrete  derivation  trees  into  abstract  derivation  trees.  (This 
map  might  be  neither  1-1  nor  onto,  in  general.  Trying  to  invert  it  is  called  “pretty-printing”,  or 
“unparsing” .) 

The  specification  of  the  function  from  concrete  to  abstract  syntax  is  quite  trivial  if  the  grammar 
for  abstract  syntax  is  obtained  systematically  from  that  for  concrete  syntax,  just  by  “unifying” 
nonterminals  and  eliminating  “chain  productions”.  In  fact  the  grammar  of  Table  2.2  was  obtained 
from  that  of  Table  2.1  (mainly)  in  that  way;  the  corresponding  map  from  concrete  to  abstract 
syntax  may  be  imagined  from  the  example  where  the  tree  in  Figure  2.1  is  mapped  to  that  in 
Figure  2.2. 

In  general,  it  is  up  to  the  semanticist  to  choose  an  appropriate  abstract  syntax  for  a  given 
language.  Different  choices  may  influence  the  difficulty  of  specifying  the  semantics.  For  instance, 
consider  the  rather  trivial  “language”  of  binary  numerals,  with  concrete  syntax  given  by  the  gram¬ 
mar  in  Table  2.3.  Of  course  the  semantics  of  binary  numerals  can  be  specified  for  the  given  syntax; 
but  it  turns  out  (as  shown  in  Section  2.3)  to  be  significantly  simpler  when  the  abstract  syntax  is 
given  by  the  grammar  in  Table  2.4.  (This  latter  grammar  is  unambiguous,  so  it  could  be  used  for 
concrete  syntax  as  well  as  abstract  syntax.  But  in  general,  the  grammars  used  for  abstract  syntax 
are  highly  ambiguous,  e.g.,  as  for  expressions  in  Table  2.2.) 

(Binary-Numeral) 

B  ::=  0  |  1  |  0  B  |  1  B 

Table  2.3:  Concrete  syntax  for  binary  numerals 


(Binary-Numeral) 

B  ::=  0  |  1  |  B  0  |  B  1 

Table  2.4:  Abstract  syntax  for  binary  numerals 

There  do  not  seem  to  be  any  hard  and  fast  rules  for  choosing  grammars  for  abstract  syntax. 
Usually,  one  has  to  compromise  between  on  the  one  hand,  keeping  close  to  a  given  grammar  for 
concrete  syntax,  and  on  the  other  hand,  facilitating  the  semantic  description. 
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Note  that  it  is  not  required  that  the  frontiers  of  the  trees  generated  by  the  abstract  grammar  are 
the  strings  generated  by  the  given  concrete  grammar,  nor  even  that  the  same  terminal  symbols  are 
used.  In  fact  some  authors  prefer  to  use  disjoint  sets  of  symbols  in  concrete  and  abstract  grammars, 
to  avoid  altogether  any  chance  of  confusion  between  concrete  and  abstract  syntax.  Here,  we  take  the 
opposite  position,  and  use  symbols  that  make  our  grammars  for  abstract  syntax  strongly  suggestive 
of  familiar  concrete  syntax. 

2.2.3  Context-sensitive  Syntax 

The  grammars  used  here  for  specifying  abstract  syntax  are  context-free.  But  it  is  well-known 
that  several  features  of  programming  languages  are  context-sensitive ,  and  cannot  be  described  by 
context-free  grammars  (e.g.,  that  identifiers  be  declared  before  they  are  referred  to,  and  that  the 
“types”  of  operands  match  their  operators). 

In  Denotations!  Semantics,  context-sensitive  syntax  is  regarded  as  a  part  of  semantics,  called 
static  semantics  (because  it  depends  only  on  the  program  text,  not  on  the  input).  For  simplicity, 
let  us  assume  that  the  static  semantics  of  a  program  is  just  a  truth-value  indicating  the  legality  of 
the  program.  Then  the  rest  of  the  semantics  of  programs  can  be  specified  independently  of  their 
static  semantics — the  semantics  of  programs  that  are  not  legal  (according  to  the  static  semantics) 
is  defined,  but  irrelevant. 

In  practice,  a  proper  treatment  of  static  semantics  might  involve  specification  of  error  messages. 
Also,  it  may  be  convenient  for  a  static  semantics  to  yiefd  abstract  syntax  that  reflects  context- 
sensitive  disambiguations  (for  instance,  whether  occurrences  of  ‘+’  are  arithmetical,  or  set  union), 
and  to  define  the  rest  of  the  semantics  on  the  disambiguated  abstract  syntax. 

Static  semantics  is  not  considered  further  in  this  chapter.  For  a  study  of  the  semantics  of  tvpes, 
see  [26]. 

So  much  for  syntax. 
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2.3  Semantics 


Consider  an  entire  program  in  some  programming  language.  What  is  the  nature  of  its  semantics? 

First  of  all  let  us  dismiss  any  effects  that  the  program  might  have  on  human  readers,  e.g.,  evoking 
feelings  of  admiration  or  (perhaps  more  often)  disgust.  In  contrast  to  philology,  programming 
linguistics  is  not  concerned  with  subjective  qualities  at  al1.  The  semantics  of  a  program  is  dependent 
only  on  the  objective  behaviour  that  the  program  causes  (directly)  when  executed  by  computers. 

Now  computers  are  complex  mechanisms,  and  all  kinds  of  things  can  be  observed  to  happen  when 
they  execute  programs:  lights  flash,  disc  heads  move,  electric  currents  flow  in  circuits,  characters 
appear  on  screens  or  on  paper,  etc.  For  programs  that  are  specifically  intended  to  control  such 
physical  behaviour,  it  would  be  necessary  to  consider  these  phenomena  in  their  semantics. 

But  here,  let  us  restrict  our  attention  to  programs  whose  behaviour  is  intended  to  be  independent 
of  particular  computers.  Such  programs  are  typically  written  in  general,  high-level  programming 
languages  that  actually  deny  the  programmer  direct  control  over  the  details  of  physical  behaviour. 
The  appropriate  semantics  of  these  programs  is  implementation-independent ,  consisting  of  just 
those  features  of  program  execution  that  are  common  to  all  implementations. 

The  implementation-independent  semantics  of  a  program  may  typically  be  modeled  mathemat¬ 
ically  as  a  function  (or  relation)  between  inputs  and  outputs — where  an  input  or  output  item  might 
be  just  a  number.  The  concrete  representation  of  input  and  output  as  strings  of  bits  is  (usually) 
implementation-dependent,  and  hence  ignored;  likewise,  the  length  of  time  taken  for  program  exccu 
tion.  But  termination  properties  are  generally  implementation- independent,  and  should  therefore 
be  taken  into  account  in  semantics.  * 

Thus  the  semantics  of  a  program  is  a  mathematical  object  that  models  the  program’s 
implementation-independent  behaviour.  The  semantics  of  a  programming  language  consists  of 
the  semantics  of  all  its  programs. 

Actually,  some  details  of  semantics  axe  often  left  implementation-defined ,  e.g..  limits  on  the 
size  of  numbers,  maximum  depth  of  recursive  activation.  These  are  regarded  as  parameters  of 
the  semantics;  when  such  parameters  are  supplied,  the  implementation-independent  semantics  of  a 
particular  subclass  of  implementations  is  obtained. 

A  standard  for  implementations  of  a  programming  language  may  be  established  by: 

(i)  specifying  the  semantics  of  all  programs  in  the  language;  and 

(ii)  specifying  a  “conformance”  relation  between  semantic  objects  and  implementation  be¬ 
haviours. 

Our  concern  in  this  chapter  is  with  (i),  but  let  us  digress  for  a  moment  to  indicate  how  (ii)  might 
be  done. 

Assume  a  correspondence  between  the  inputs  and  outputs  in  the  semantic  model  and  some 
physical  objects  processed  by  implementations.  Let  a  program  and  its  input  be  given.  If  these 
uniquely  determine  output  (and  termination  properties)  then  a  conforming  implementation,  when 
given  the  physical  representations  of  the  program  and  input,  must  produce  a  representation  of  the 
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output — computing  “for  ever”  if  the  semantics  specifies  non-termination.  If,  however,  there  are 
several  possible  outputs  for  a  given  program  and  input — i.e.,  the  program  is  nondeterministic-the 
implementation  need  only  produce  one  of  them  (perhaps  not  terminating  if  that  is  a  possibility); 
the  implementation  may  or  may  not  be  nondeterministic  itself. 

2.3.1  Denotations 

Now  back  to  our  main  concern:  specifying  the  semantics  of  programs.  The  characteristic  feature  of 
Denotations!  Semantics  is  that  one  gives  semantic  objects  for  all  phrases — not  only  for  complete 
programs.  The  semantic  object  specified  for  a  phrase  is  called  the  denotation  of  the  phrase.  The 
idea  is  that  the  denotation  of  each  phrase  represents  the  contribution  of  that  phrase  to  the  semantics 
of  any  complete  program  in  which  it  may  occur. 

The  denotations  of  compound  phrases  must  depend  only  on  the  denotations  of  their  subphrases. 
(Of  course*  the  denotations  of  basic  phrases  do  not  depend  on  anything.)  This  is  called  composi- 
tionality. 

It  should  be  noted  that  the  semantic  analyst  is  free  to  choose  the  denotations  of  phrases — 
subject  to  compositionality.  Sometimes  there  is  a  “natural”,  optimal  choice,  where  phrase,  have  the 
same  denotations  whenever  they  are  interchangeable  (without  altering  behaviour)  in  all  complete 
programs ;  then  the  denotations  are  called  fully  abstract ,  and  they  capture  just  the  “essential” 
semantics  of  phrases. 

Note  that  considering  interchangeability  only  in  complete  programs  lets  the  notion  of  full  ab¬ 
stractness  refer  directly  to  the  behaviours  of  programs,  rather  than  to  their  denotations.  Different 
choices  of  which  phrases  are  regarded  as  complete  programs  may  give  different  conclusions  con¬ 
cerning  whether  full  abstractness  obtains. 

It  is  not  always  easy  (or  even  possible)  to  find  and  specify  fully  abstract  denotations,  so  in 
practice  a  compromise  is  made  between  simplicity  and  abstractness. 

As  an  introductory  (and  quite  trivial)  example  take  the  binary  numerals.  An  abstract  syntax 
for  binary  numerals  was  suggested  in  Section  2.2.  Now  let  us  extend  the  syntax  to  allow  “programs” 
consisting  of  signed  binary  numerals,  see  Table  2.5. 

(Signed-Binary- Numeral) 

Z  ::=  B  |  -  B 

(Binary-Numeral) 

B  ::=  0  |  1  |  B  0  |  B  1 

Table  2.5:  Abstract  syntax  for  signed  binary  numerals 

The  meanings  (i.e.,  “behaviours”)  of  signed  binary  numerals  are  supposed  to  be  integers  in 
Z,  according  to  the  usual  interpretation  of  binary  notation  (i.e.,  the  most  significant  bit  is  the 
left-most),  negated  if  preceded  by  We  are  free  to  choose  the  denotations  for  unsigned  binary 
numerals  B.  The  natural  choice  is  to  let  each  B  denote  the  obvious  natural  number  in  N.  and  such 


denotations  (specified  formally  in  Section  2.3.2)  are  indeed  fully  abstract. 

Any  other  choice  of  denotations  is  perhaps  rather  contrived  in  this  simple  example,  but  let  us 
consider  an  alternative  possibility  so  as  to  illustrate  lack  of  full  abstractness. 

We  could  choose  the  denotation  of  £  to  be  a  pair  (n, /)  G  N2,  where  n  gives  the  numerical  value 
of  B  and  l  gives  its  length.  Then  the  denotation  of  a  signed  binary  numeral  ‘2?’  or  ‘-5’  would 
be  determined  just  by  n.  Such  denotations  can  be  defined  compositionally,  but  they  are  not  fully 
abstract:  for  instance,  the  phrases  ‘O’  and  ‘00’  get  distinct  denotations,  yet  they  can  always  be 
interchanged  in  any  signed  binary  numeral  without  affecting  its  meaning. 

Now  consider  the  original  (concrete)  grammar  for  unsigned  binary  numerals  (Table  2.4)  and 
regard  it  as  a  specification  of  abstract  syntax.  With  this  phrase  structure,  we  are  no  longer  able  to 
take  the  denotation  of  B  to  be  just  its  numerical  value:  the  value  of  the  phrase  ‘1 B'  is  determined 
not  only  by  the  numerical  value  of  B,  but  also  by  the  number  of  its  leading  zeros.  In  fact  the 
( n,l )  G  N2  denotations  mentioned  above  turn  out  to  be  fully  abstract  for  this  syntax. 

The  above  example  shows  that  the  property  of  full  abstractness  can  be  rather  sensitive  to 
the  structure  of  abstract  syntax — and  thereby  casts  doubt  on  its  appropriateness  as  an  absolute 
criterion  of  the  quality  of  denotational  descriptions. 

In  Denotational  Semantics,  there  is  in  general  a  sharp  distinction  between  syntax  and  seman¬ 
tics,  and  denotations  consist  of  mathematical  objects  (such  as  numbers  and  functions)  that  exist 
completely  independently  of  programming  languages.  In  particular,  denotations  do  not  usually 
incorporate  program  phrases  as  components.  In  fact  it  would  not  conflict  with  compositional- 
ity  to  let  phrases  denote  even  themselves,  but  such  “denotations”  tend  to  ha\'e  (extremely)  poor 
abstractness. 

There  are  two  cases,  however,  when  it  is  desirable  to  use  phrases  as  denotations: 

•  identifiers  usually  have  to  be  their  own  denotations  (e.g.,  in  declarations);  and 

•  for  languages  like  Lisp,  where  phrases  can  be  computed ,  the  denotation  of  a  phrase  essentially 
corresponds  to  its  abstract  syntax  (and  the  benefits  of  the  denotational  approach  are  then 
questionable,  since  semantic  equivalence  is  just  syntactic  identity). 

2.3.2  Semantic  Functions 

Semantic  functions  map  phrases  (of  abstract  syntax)  to  their  actual  denotations.  The  semantics  of 
a  programming  language  may  be  specified  by  defining  a  semantic  function  for  each  sort  of  phrase. 

Recall  that  abstract  syntactic  entities  have  an  unambiguous  structure.  Hence  semantic  functions 
may  be  defined  inductively  by  specifying,  for  each  syntactic  construct,  its  denotation  in  terms  of 
the  denotations  of  its  components  (if  there  are  any).  The  conventional  way  of  writing  such  an 
inductive  definition  in  Denotational  Semantics  is  as  a  set  of  so-called  semantic  equations .  with  (in 
general)  one  semantic  equation  for  each  production  of  the  abstract  syntax. 

Let  a,  a\,  . . . ,  an  be  (possibly-subscripted)  nonterminal  symbols,  with  associated  phrase  sorts 
s'  5i . 3n ■  Let  ...,  T,n  be  sen  tic  functions  mapping  phrases  of  sort  s(l)  to  their 
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denotations  (in  practice,  the  semantic  functions  are  usually  given  mnemonic  names  when  they  are 
introduced).  Then  the  semantic  equation  for  the  production  ‘a  ::=  uoai  . . .  anun’  is  of  the  form 

Uoai  ■  •  -OnUn  ]  =  /(•^»ilal]»  •  •  •  lenten])- 

The  way  that  the  denotations  of  the  phrases  ai,  ... ,  an  are  combined  is  expressed  using  whatever 
notation  is  available  for  specifying  particular  objects — determining  a  function,  written  /  above. 

Note  that  the  emphatic  brackets  [  J  separate  the  realm  of  syntax  from  that  of  semantics,  which 
avoids  confusion  when  programming  languages  contain  the  same  mathematical  notations  as  are 
used  for  expressing  denotations. 

To  illustrate  the  form  of  semantic  equations,  let  us  specify  denotations  for  signed  binary  numer¬ 
als  (with  the  abstract  syntax  given  in  Table  2.5).  We  take  for  granted  the  ordinary  mathematical 
notation  (0, 1,2, +,— ,  x)  for  specifying  particular  integers  in  Z  and  natural  numbers  in  N.  The 
semantic  functions  ( Z  for  signed  binary  numerals,  B  for  unsigned  binary  numerals)  are  defined 
inductively  by  the  semantic  equations  given  in  Table  2.6. 

2  :  Signed-Binary-Numeral  -<•  Z 
2[B]  =  B[B\ 

21-  B)  =  -B[B] 

B  :  Binary-Numeral  -►  N 
B[  0  ]  =  0 

B[  1  I  =1 

B[  B  0  ]  =  2  x  (£[£]) 

B[  B  1  ]  =  (2  x  (5[2?]))  +  1 

Table  2.6:  Denotations  for  signed  binary  numerals 

Perhaps  the  standard  interpretation  of  binary  notation  is  so  much  taken  for  granted  that  we 
may  seem  to  be  merely  “stating  the  obvious”  in  the  semantic  equations.  But  we  could  just  as  well 
have  specified  alternative  interpretations,  e.g.,  by  reversing  the  roles  of  ‘0’  and  ‘1',  or  by  making 
the  right-most  bit  the  most  significant. 

In  effect,  the  semantic  equations  reduce  the  semantics  of  the  language  described  (here,  the  binary 
numerals)  to  that  of  a  “known”  language  (here,  that  of  ordinary  arithmetic).  This  reduction  may 
also  be  viewed  as  a  “syntax-directed  translation”,  although  it  is  then  essential  to  bear  in  mind  that 
phrases  are  semantically-equivalent  whenever  they  are  translated  to  notation  that  has  the  same 
interpretation ,  not  merely  the  same  form. 


60 


An  alternative  way  of  specifying  semantic  functions  is  to  exploit  the  formulation  of  abstract 
syntax  as  an  initial  algebra,  discussed  in  Section  2.2.  Recall  that  the  abstract  syntax  A{G)  specified 
by  a  grammar  G  is  a  Ec-algebra,  where  La  is  the  signature  corresponding  to  the  productions  of 
G.  As  A(G)  is  the  initial  E<;-algebra  (Proposition  32),  there  is  a  unique  Ec-homomorphism  from 
*4(G0  to  any  other  E^-algebra.  So  all  that  is  needed  is  to  make  the  spaces  of  denotations  into  a 
“target”  E<?-algebra,  say  D,  by  defining  a  function  pa  for  each  p  6  La,  i.e.,  for  each  production  p 
of  G.  Then  the  semantic  functions  are  given  as  the  components  of  the  unique  Eo-homomorphism 
from  A(G)  to  D. 

This  approach  is  known  as  Initial  Algebra  Semantics.  Whereas  such  an  explicit  algebraic  for¬ 
mulation  can  be  convenient  for  some  purposes,  the  approach  is  essentially  the  same  as  Denotational 
Semantics,  and  it  is  a  simple  matter  to  transform  semantic  equations  into  specifications  of  target 
algebras — or  vice  versa — while  preserving  the  semantic  functions  that  are  thereby  defined. 

2.3.3  Notational  Conventions 

Some  abbreviatory  techniques  are  commonly  used  in  semantic  equations: 

•  The  semantics  of  a  construct  may  be  specified  in  terms  of  that  of  a  compound  phrase,  provided 
no  circularity  is  introduced  into  the  inductive  definition.  For  instance,  we  might  specify 

<S[  if  E  then  5  ]  =  «S[  if  E  then  S  else  skip  ] 

where  «S[  if  E  then  Si  else  S2  ]  is  specified  by  an  ordinary  semantic  equation.  As  well  as 
abbreviating  the  right-hand  sides  of  semantic  equations,  the  use  of  this  technique  emphasizes 
that  the  syntactic  construct  is  just  “syntactic  sugar”  and  does  not  add  anything  of  (semantic) 
interest  to  the  language. 

•  There  may  be  several  semantic  functions  for  a  single  phrase  sort,  say  F  :  P  —  Z?,.  This 
corresponds  to  a  single  function  T  :  P  -*  {D\  x  . . .  x  £>„),  with  the  components  of  denotations 
being  defined  separately. 

•  The  names  of  semantic  functions  may  be  omitted  (when  there  is  no  possibility  of  confusion). 
In  particular,  when  identifiers  are  essentially  their  own  denotations,  their  (injective)  semantic 
function  is  generally  omitted. 

These  abbreviations  have  been  found  to  increase  the  readability  of  denotational  descriptions 
without  jeopardizing  their  formality. 


61 


2.4  Domains 


Appropriate  mathematical  spaces  for  the  denotations  of  programming  constructs  are  called  (se¬ 
mantic)  domains.  Here,  after  a  brief  introduction  to  the  basic  concept  of  a  domain,  a  summary  is 
given  of  the  notation  used  for  specifying  domains  and  their  elements.  A  thorough  explanation  of 
the  notation,  together  with  the  theory  of  domains,  is  given  by  Gunter  and  Scott  [18].  The  main 
techniques  for  choosing  domains  for  use  in  denotational  descriptions  of  programming  languages  are 
demonstrated  in  Section  2.5. 

2.4.1  Domain  Structure 

Domains  are  sets  whose  elements  are  partially-ordered  according  to  their  degree  of  “definedness”. 
When  x  is  less  defined  than  y  in  some  domain  D,  we  write  x  C d  V  and  say  that  x  approximates  y 
in  D.  (Mention  of  the  domain  concerned  may  be  omitted  when  it  is  clear  from  the  context.)  Every 
domain  D  is  assumed  to  have  a  least  element  _1_£,  representing  “undefinedness”;  moreover  there 
are  limits  |Jn  xn  for  all  (countable)  increasing  sequences  io  C  ii  C  ■  •  •  C  C  •  •  •.  (Thus  domains 
are  so-called  (u-)cpos.  Further  conditions  on  domains  are  imposed  by  Gunter  and  Scott  [18];  but 
these  conditions  need  not  concern  us  here,  as  their  primary  purpose  is  to  ensure  that  the  class  of 
domains  is  closed  under  various  constructions.) 

For  an  example,  consider  the  set  of  partial  functions  from  N  to  N,  and  for  partial  functions 
f,g,  let  f  Q  g  iff  graph(/)  C  graph(<7).  This  gives  a  domain:  C  is  a  partial  order  corresponding 
to  definedness;  the  least  element  J.  is  the  empty  function  (but  every  total  function  is  maximal,  so 
there  is  no  greatest  element);  and  the  limit  of  any  increasing  sequence  of  functions  is  given  by  the 
union  of  the  graphs  of  the  functions. 

A  domain  D  may  be  defined  simply  by  specifying  its  elements  and  it  approximation  relation  C, 
as  above.  But  it  is  tedious  to  check  each  time  that  C  has  the  required  properties — and  to  define 
ad  hoc  notation  for  identifying  elements. 

In  practice,  the  domains  used  in  denotational  descriptions  are  generally  defined  as  solutions 
(up  to  isomorphism)  of  domain  equations  involving  the  standard  primitive  domains  and  standard 
domain  constructions.  Not  only  does  this  ensure  that  the  defined  structures  really  are  domains,  it 
also  provides  us  with  standard  notation  for  their  elements. 

The  standard  primitive  domains  are  obtained  merely  by  adding  _L  to  an  unordered  (but  at  most 
countable)  set,  of  course  letting  i  C  x  for  all  x.  Domains  with  such  a  trivial  structure  are  called 
flat.  For  example  the  domain  T  of  truth  values  is  obtained  by  adding  J.  to  the  set  {true,  false},  and 
the  domain  Nj_  of  natural  numbers  by  adding  J.  to  N. 

There  are  standard  domain  constructions  that  correspond  closely  to  well-known  set  construc¬ 
tions:  Cartesian  product,  disjoint  union,  function  space,  and  power  sets.  Of  course  these  domain 
constructions  have  to  take  account  of  the  C  relation,  as  well  as  the  elements;  this  leads  to  several 
possibilities. 

Before  proceeding  to  the  details  of  the  standard  domain  notation,  let  us  consider  what  functions 
between  domains  are  required. 


62 


The  functions  generally  needed  for  the  semantics  of  programming  languages  are  monotone,  in 
that  they  preserve  the  relation  C: 

x  C  y  implies  /(x)  C  /(y); 

and  continuous ,  in  that  they  also  preserve  limits  of  increasing  sequences: 
xoCxiC-.-CxnC...  implies  /((Jxn)  =  Li  /  On)- 

n  n 

Note  that  we  do  not  insist  that  functions  preserve  least  elements.  Those  functions  /  that  do  satisfy 

/( ±)  =  J- 

are  called  strict.  Constant  functions  are  non-strict  functions  (in  general). 

Partial  functions  from  N  to  N  are  represented  by  strict  total  functions  from  Nj.  to  Nj_,  the 
result  ±  corresponding  to  “undefined”.  Notice,  by  the  way,  that  all  strict  functions  on  Nj.  are 
continuous — but  in  practice,  we  only  make  use  of  those  that  are  computable  in  the  usual  sense. 
The  importance  of  continuity  is  two-fold: 

(i)  Let  D  be  a  domain.  For  any  continuous  function  /  :  D  — ►  D  there  is  a  least  x  £  D  such  that 

x  =  /(x). 

This  x  is  called  the  least  fixed  point  of  /,  written  fix(/).  It  is  given  by  [_|n  /n(i.). 

Non-monotone  functions  on  domains  need  not  have  fixed  points  at  all;  whether  monotone 
(but  non-continuous)  functions  on  domains  always  have  least  fixed  points  depends  on  the 
precise  structure  of  domains,  but  in  any  case  their  fixed  points  are  not  necessarily  obtainable 
as  the  limits  of  countable  increasing  sequences. 

(ii)  There  exists  a  non-trivial  domain  Doo  such  that 

Doo  —  Doo  Doo 

provided  that  — *  Doo  is  just  the  space  of  continuous  functions  on  Doo-  Domains  such  as 

Doo  that  “contain”  their  own  (continuous)  function  space  are  called  reflexive. 

If  Doo  — *  Dr0  were  to  be  the  space  of  all  functions,  Doo  would  have  to  be  the  trivial  (one-point) 
domain,  by  Cantor’s  Theorem. 

Least  fixed  points  of  continuous  functions  provide  appropriate  denotations  for  iterative  and 
recursive  programming  constructs.  Reflexive  domains  are  needed  for  the  denotations  of  constructs 
that  may  involve  “self- application”:  procedures  with  procedure  parameters  in  Algol60,  functions 
with  dynamic  bindings  in  Lisp,  assignments  of  procedures  to  variables  in  C,  etc.  Even  when  self¬ 
application  is  forbidden  (e.g.,  by  type  constraints),  it  may  still  be  simpler  to  specify  denotations  as 
elements  of  reflexive  domains,  rather  than  to  introduce  infinite  families  of  non-reflexive  domains. 

The  structure  of  domains  described  above  is  further  motivated  by  the  fact  that  domains  with 
continuous  functions  provide  denotations  for  almo&t  all  useful  programming  constructs.  (The  only 
exception  seems  to  be  constructs  that  involve  so-called  “unbounded  nondeterminism”,  correspond¬ 
ing  to  infinite  sets  of  implementation-dependent  choices.) 
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2.4.2  Domain  Notation 


Now  for  a  summary  of  the  notation  for  specifying  domains  and  their  elements,  following  Gunter 
and  Scott  [18].  The  (abstract)  syntax  of  the  notation  is  given  in  Table  2.7.  Some  conventions  for 
disambiguating  the  written  representation  of  the  notation,  together  with  some  abbreviations  for 
commonly-occurring  patterns  of  notation,  are  given  in  Section  2.4.3. 


(Domain-Expressions) 

d  ::=  ID  1  1  |  0  1  T  1  Nx  | 
d\  — >4^2  |  d\  o— *  d%  | 
d\  X  •  •  •  X  dn  |  d\  ®  ®  dn  | 

d\  4-  •  •  •  4-  dn  j  di  ®  •  •  •  $  dn  | 
d±  |  d*  |  d°°  |  d* 

(Domain- Variables) 

w  ::=  arbitrary  symbols 

(Expressions) 

e  ::=  x  |  ±d  |  T  |  true  |  false  | 

ei  =d  e2  |  if  then  e2  else  e3  |  0 

1  succ  1 

Ax  6  d.  e  |  ex  C2  1  'dd  \ 

fi *d  I  strict^  | 

(ea,...,en)  |  (ex,...,en)  |  on?  | 

smashd  | 

[ex,...,en]  |  in?  |  upd  \  down* 
M  1  eiUej  |  e*  |  extd 

(Variables) 

x  ::=  arbitrary  symbols 

Table  2.7:  Notation  for  domains  and  elements 


Let  us  start  with  domain  expressions ,  d.  These  may  include  references  to  domain  variables ,  w, 
whose  interpretation  is  supplied  by  the  context  of  the  domain  expression.  This  context  is  generally 
a  set  of  domain  equations  of  the  form 

ini  =  dt , . . . ,  wn  =  dn 

where  the  twj  are  distinct  and  no  other  variables  occur  in  the  d,.  As  is  shown  by  Gunter  and  Scott 
[18],  there  is  always  a  “minimal”  solution  to  such  a  set  of  equations  (up  to  isomorphism).  We  need 
not  worry  here  about  the  construction  of  the  solution — the  equations  themselves  express  all  that 
we  really  need  to  know  about  the  defined  domains.  Note,  however,  that  the  simple  equation 

D  =  D  -  D 
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defines  D  to  be  the  trivial  (cne-point)  domain!  Most  domain  equations  that  arise  in  practice  do 
not  admit  trivial  solutions.  (Gunter  and  Scott  [18]  show  how  to  force  non- trivial  solutions  to 
D  =  D  -*  D.) 

Element  expressions  e  may  include  references  to  element  variables  x  whose  domain  and  inter¬ 
pretation  is  supplied  by  the  context.  Usually  the  context  is  just  the  enclosing  (element)  expression, 
but  we  also  allow  auxiliary  definitions  of  the  form 

x  =  e  e  d 

The  scope  of  an  auxiliary  definition  is  the  entire  specification.  (Mutually-dependent  auxiliary 
definitions  may  be  regarded  as  abbreviations  for  independent  definitions  involving  the  least  fixed 
point  operator.) 

Basic  Domains 

denotes  the  least  element  of  a  domain  d. 

I  is  the  1-point  domain,  consisting  only  of  ±|. 

0  is  the  2-point  domain,  consisting  of  _Lo  and  T.  (Domains  do  not  usually  have  greatest  elements, 
so  there  is  no  need  for  a  general  notation  Tj.) 

Truth  Values 

T  is  the  flat  3-point  domain  of  truth  values,  consisting  of  ±j,  tnie,  and  false. 

ei  =d  tests  the  equality  of  ex  and  in  any  flat  domain  d.  The  value  is  _Lt  if  either  or  both  of 
ex  and  e2  denote  otherwise  it  is  true  or  false.  (The  monotonicity  and  continuity  of 
follow  from  the  flatness  of  d:  equality  would  not  be  monotonic  on  a  non-flat  domain.) 

if  ex  then  e2  elsee3  requires  ex  to  denote  an  element  of  T,  and  e2,  e3  to  denote  elements  of  some 
domain  d.  Then  it  denotes  e2  if  ex  denotes  true;  it  denotes  e3  if  ex  denotes  false;  and  it  denotes 
±d  if  ex  denotes  ±r- 

In  practice  we  allow  all  the  usual  Boolean  functions,  extended  strictly  (in  all  arguments)  to  T, 
and  written  using  infix  notation. 

Natural  Numbers 

Nx  is  the  flat  domain  of  natural  numbers,  consisting  of  ±nx,  0,  1,  . . .  (no  infinity), 
succ  denotes  the  strict  extension  of  the  successor  function  from  N  to  Nj.. 

In  practice  we  allow  all  known  (computable)  functions  on  the  natural  numbers,  extended  strictly 
in  all  arguments  to  Nj.,  and  written  using  infix  notation. 
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Function  Domains 


di  —  d-2  denotes  the  domain  of  all  continuous  functions  from  the  domain  denoted  by  d\  to  the 
domain  denoted  by  d 2.  (Henceforth  the  tedious  “denoted  by”  is  generally  omitted.)  We  have 
/  Qdi—di  9  iff  f(x)  Qd,  g(x)  for  all  x  in  dj. 

Ax  €  d.  e  denotes  the  (continuous)  function  /  given  by  defining  /(x)  =  e,  where  x  ranges  over  d. 
This  provides  the  context  for  interpreting  references  to  x  in  e. 

e-i  e-i  denotes  the  result  /(x)  of  applying  the  function  f  :  d  -*  d'  denoted  by  e\  to  the  value  x  6  d 
denoted  by  e 2. 

id,*  denotes  the  identity  function  on  domain  d. 

e\  0  ej  denotes  the  composition  of  the  functions  f\  :  d'  —*  d"  and  :  d  — »•  d'  denoted  by  e\  and  e2, 
respectively,  so  that  for  all  x  €  d,  (ei  o  e2)(x)  =  ei(e2(x)). 

fix<i  denotes  the  least  fixed  point  operator  for  domain  d,  which  maps  each  function  /  in  d  — *  d  to 
the  least  solution  x  of  the  equation  x  =  /(x). 

d\  o-+  di  denotes  the  restriction  of  d\  — *■  d2  to  strict  functions. 

strict^  denotes  the  function  that  maps  each  function  in  d\  — ♦  d%  to  the  corresponding  strict  function 
in  d,  where  d  =  d\  o-+  d2. 

Product  Domains 

dj  x  •  •  •  x  dn  denotes  the  Cartesian  product  domain  of  n-tuples,  for  any  n  >  2,  generalizing  the 

binary  product  domain  of  pairs.  We  have  (xx, . . .  ,xn)  Cdl  x...xdn  (j/i . y„)  iff  x,  Cdt  y,  for 

i  = 

(ex, . . .  ,en)  denotes  the  n-tuple  with  components  e\, . . . ,  e„,  for  any  n  >  2. 

(elt...,en)  denotes  the  target  tupling  of  the  functions  denoted  by  the  e,\  abbreviating 
Ax  e  d.  (ei(x), . . .  ,en(x)),  where  x  does  not  occur  in  the  e,-. 

onf  denotes  the  projection  onto  the  i’th  component,  mapping  (xi,...,xn)  to  i;  ,  where  d  = 
d\  x  ■  •  •  x  dn. 

dj  0  ■  •  •  ®  dn  denotes  the  “smash”  product  obtained  from  the  Cartesian  product  by  identifying  all 
the  n-tuples  that  have  any  J.  components.  Note  that  g>  preserves  flatness  of  domains. 

smash,*  denotes  the  function  that  maps  each  element  of  d,  where  d  =  d\  x  ■  •  •  x  dn,  to  the  corre¬ 
sponding  element  of  $•••£>  dn,  giving  X  if  any  of  the  components  are  X. 
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Sum  Domains 

dx  + - 1-  dn  denotes  the  “separated”  sum  domain  d  whose  elements  are  (distinguished  copies  of) 

the  elements  of  the  d,  together  with  a  new  _!_<*.  Elements  of  d  originating  from  different 
summands  d,-  are  incomparable  in  d. 

dx  0  •••  ©  dn  df notes  the  “coalesced”  sum  domain  d  where  the  ±  elements  of  (the  distinguished 
copies  of)  the  d,  are  identified  with  J .d.  Note  that  ®  preserves  flatness  of  domains. 

inf  denotes  the  injection  function  mapping  elements  of  dt-  to  the  corresponding  elements  of  d,  where 
d  =  d\  ®  •  •  •  ®  dn  and  1  <  i  <  n. 

[ei,...,en]  denotes  the  “case  analysis”  of  the  functions  /,•  :  d,  — ►  d'  denoted  by  the  e,,  mapping 
in<(x)  to  the  value  of  /,(x)  for  1  <  *  <  n  (but  mapping  1  to  J_). 

Lifted  Domains 

dx  denotes  the  lifted  domain  d!  obtained  by  adding  a  new  ±d>  under  (a  distinguished  copy  of)  d. 

upj  denotes  the  function  that  maps  each  element  of  d  to  the  corresponding  element  of  dx- 

down^  denotes  the  function  that  maps  each  element  of  dx  back  to  the  corresponding  element  of  d. 

Lists 

d*  denotes  the  domain  of  lists  of  finite  length,  with  non-i.components  in  d.  Note  that  lists  with 
different  lengths  are  incomparable  in  C. 

d°°  denotes  the  domain  of  infinite  lists  with  components  in  d.  Here,  the  “empty”  list  is  the  infinite 
list  of  J_’s.  We  let  l\  Cd<x>  li  iff  every  component  of  /j  approximates  the  corresponding 
component  of  l?.  Thus  the  empty  list  approximates  all  other  lists. 

Power  Domains 

d*  denotes  the  “natural”  (convex,  Plotkin)  power  domain.  Its  elements  may  be  imagined  as  equiv¬ 
alence  classes  of  sets,  where  two  sets  are  equivalent  iff  this  follows  from  the  continuity  (and 
associativity,  commutativity  and  absorption)  of  the  binary  union  operation. 

E.g.,  if  x  C  y  C  z,  then  the  sets  {x,y,z}  and  {x,z}  are  equivalent;  moreover,  if  xo  C  xi  C 
•  •  •  C  x„  C  •  •  •  and  X  =  {xn  J  0  <  n},  then  X  is  equivalent  to  X  U  (|Jn  x„}. 

The  other  power  domains  (upper,  lower)  considered  by  Gunter  and  Scott  [18]  are  not  used  in 
this  chapter:  they  do  not  accurately  reflect  the  possibility  of  non-termination,  as  they  force 
sets  X  U  {-L}  to  be  equivalent  either  to  {x}  or  to  X. 

{ej  denotes  the  element  of  d6  corresponding  to  the  set  {x},  where  e  denotes  the  element  x  6  d. 
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e\  U  e.'i  denotes  the  element  of  d 3  corresponding  to  the  union  of  Xi  and  X%,  where  e\  and  e 2  denote 
elements  of  a  power  domain  d°  corresponding  to  the  sets  .Yi  and  X^. 

denotes  the  pointwise  extension  of  e  to  map  rfi  **  — ►  d2l),  where  e  denotes  a  function  in  d\  — *  d^. 

ex tj  extends  functions  in  d  =  d\  — ►  ^2^  to  d^  —*  d^\ 

It  is  possible  to  represent  the  empty  set  by  using  the  domain  0  ©d*1  instead  of  just  d*1;  emptiness 
can  be  tested  for  using  [Ax  £  0.  ei,Ax  g  dl  e2].  However,  there  is  no  (continuous)  test  for 
membership  in  power  domains  (just  as  there  is  no  continuous  test  for  equality  on  non-flat  domains). 
So  much  for  the  basic  notation  for  domains  and  their  elements. 

2.4.3  Notational  Conventions 

When  the  above  notation  is  written  in  semantic  descriptions,  domain  expressions  in  element  ex¬ 
pressions  are  generally  omitted  when  they  can  be  deduced  from  the  context.  Parentheses  are  used 
to  indicate  grouping,  although  the  following  conventions  allow  some  parentheses  to  be  omitted: 

•  Function  domain  constructions  — *  and  o— *•  associate  to  the  right,  and  have  weaker  precedence 
than  -r,  ©,  x,  and  ®: 

D\  x  D-x  — ►  D3  -*  D+  is  grouped  as  (D\  x  D2)  — ►  (£3  — 1 •  D4). 

•  Application  is  left-associative,  and  has  higher  precedence  than  the  other  operators:  f  xy  is 
grouped  as  (/  x)  y,  and  /  o  g(x)  is  grouped  as  /  o  (^(x)); 

•  Abstraction  Ax  €  d.  e  extends  as  far  as  possible:  (Ax  £  D.  f  x)  is  grouped  as  (Ax  £  D.  (/  x)); 

•  Composition  0  is  associative,  so  its  iteration  does  not  need  grouping. 

(Without  these  conventions,  our  semantic  descriptions  would  require  an  uncomfortable  number  of 
parentheses.)  Furthermore,  when  implied  unambiguously  by  the  context,  the  following  operations 
may  be  omitted: 

•  isomorphism  between  w  and  d,  when  w  =  d  is  a  specified  domain  equation; 

•  the  following  isomorphisms  (which  follow  from  the  definitions  of  the  basic  domains  and  domain 
constructors): 

-  d\  +  •  •  •  +  dn  2  (di)x  ©  •  •  ■  ©  (d„)_i_; 

-  0SIX; 

-  T  2  (0  ©  0),  mapping  true  to  ini(_Lo); 

-  Nj.  2  (0  ©  Nx),  mapping  0  to  ini(J_o); 

-  d*  ^  (0  ®(d®d’)); 

-  d°°  *  (d  x  d°°); 
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-  d°°  *  (Nxo-*d): 

•  injections  in*  :  d,  o— ►  d\  ©  •  •  •  ©  dn\ 

•  “bottom  extensions”  of  functions  /  :  di  — *■  d!  to  sum  domains: 

[.  •  • ,  JL,  /,  J., . . .]  :  di  ©  •  •  •  ©  dn  o-*.  (f; 

•  the  inclusions  of  d\  ®  •  •  •  ®  dn  in  d\  X  •  •  •  x  dn  and  of  d  o-*  d'  in  d  — *  df ,  and  the  strict  inclusion 
of  d\  ®  —  ©  dn  in  d\  4-  •  •  •  +  dn . 

Finally,  the  notation  A(xi  G  di,...,xn  G  dn).  e  abbreviates 

Ax  €  di  X  •  •  •  x  dn.  (Axi  G  d\ .  •  •  •  Axn  g  dn.  e)(onix)  •  •  •  (on„x) 

(where  x  does  not  occur  in  e).  It  denotes  the  function  /  defined  by  /(xlf . . . ,  x„)  =  e. 
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2.5  Techniques 


The  preceding  sections  introduced  all  the  formalism  that  is  needed  for  specifying  denotational 
descriptions  of  programming  languages:  grammars,  for  specifying  abstract  syntax;  domain  notation, 
for  specifying  domains  and  their  elements;  and  semantic  equations,  for  specifying  semantic  functions 
mapping  syntactic  entities  to  their  denotations. 

This  section  gives  some  examples  of  denotational  descriptions.  The  main  purpose  of  the  exam¬ 
ples  is  to  show  what  techniques  are  available  for  modeling  the  fundamental  concepts  of  programming 
languages  (sequential  computation,  scope  rules,  local  variables,  etc.). 

Familiarity  with  these  techniques  allows  the  task  of  specifying  a  denotational  semantics  of  a 
language  to  be  factorized  into  (i)  analyzing  the  language  in  terms  of  the  fundamental  concepts,  and 
(ii)  combining  the  techniques  for  modeling  the  concepts  involved.  Furthermore,  the  understanding 
of  a  given  denotational  description  may  be  facilitated  by  recognition  of  the  use  of  the  various 
techniques. 

The  programming  constructs  dealt  with  in  the  examples  below  are,  in  general,  simplified  versions 
of  constructs  to  be  found  in  conventional  “high-level”  programming  languages.  It  is  not  claimed 
that  the  agglomeration  of  the  exemplified  constructs  would  make  a  particularly  elegant  and/or 
practical  programming  language. 

Section  2.5.1  outlines  the  semantics  of  literals  (numerals,  strings,  etc.).  Then  Section  2.5.2 
specifies  denotations  for  arithmetical  and  Boolean  expressions ,  illustrating  a  simple  technique  for 
dealing  with  “errors”.  Section  2.5.3  shows  how  to  specify  denotations  for  constant  declarations , 
using  “environments”  to  model  scopes.  Section  2.5.4  extends  expressions  to  include  function  ab¬ 
stractions ,  and  gives  a  denotational  description  of  the  A -calculus. 

Next,  Section  2.5.5  gives  denotations  for  variable  declarations ,  using  “stores"  and  “locations”. 
Then  Section  2.5.6  deals  with  statements ,  using  “direct”  semantics;  it  also  explains  how  the  tech¬ 
nique  of  “continuations”  can  be  used  to  model  jumps.  Section  2.5.7  describes  procedures  with 
various  modes  of  parameter  evaluation. 

Section  2.5.8  distinguishes  between  the  concepts  of  “batch”  and  “interactive"  input  and  output. 
Section  2.5.9  shows  how  powerdomains  can  be  used  to  model  nondeterministic  programs.  Finally, 
Section  2.5.10  introduces  “resumptions”  and  uses  them  to  give  denotations  for  a  simple  form  of 
concurrent  processes. 

Caveat:  In  Section  2.5.2,  the  denotations  of  expressions  are  simply  (numerical,  etc.)  values. 
But  later,  they  have  to  be  changed :  in  Section  2.5.3  (to  be  functions  of  environments),  and  again  in 
Section  2.5.5  (to  be  functions  of  stores).  Such  changes  to  denotations  entail  tedious  changes  to  the 
semantic  equations  that  involve  them.  This  rather  unfortunate  feature  of  conventional  denotational 
descriptions  stems  from  the  fact  that  the  notation  used  in  the  semantic  equations  has  to  match  the 
precise  domain  structure  of  denotations. 

Of  course,  these  changes  would  be  unnecessary  if  denotations  of  expressions  were  to  be  functions 
of  environments  and  stores  from  the  start.  Although  that  might  be  appropriate  when  giving  a 
denotational  description  of  a  complete  programming  language,  it  is  undesirable  in  this  introduction: 
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the  complexity  of  the  denotations  of  simple  constructs  would  obscure  the  relation  between  particular 
program  constructs  and  the  appropriate  techniques  for  modeling  them. 

An  alternative  approach  is  to  introduce  auxiliary  notation  for  combining  denotations.  Then 
when  domains  of  denotations  are  changed,  only  the  definition  of  the  auxiliary  notation  requires 
modification:  the  semantic  equations  themselves  may  be  left  unchanged.  Moreover,  the  auxiliary 
notation  may  be  chosen  to  correspond  directly  to  fundamental  concepts,  such  as  “sequencing”  and 
“block  structure”,  so  that  the  semantic  equations  explicate  the  fundamental  conceptual  analysis  of 
the  described  constructs.  Such  an  approach  is  presented  elsewhere  [34].  It  would  be  inappropriate 
to  adopt  it  here,  as  it  tends  to  hide  the  mathematical  essence  of  denotations,  and  would  give  a 
distorted  impression  of  the  conventional  approach  to  Denotational  Semantics. 

2.5.1  Literals 

The  syntax  of  a  programming  language  usually  includes  “literals”  (sometimes  called  “literal  con¬ 
stants”,  or  just  “constants”).  A  literal  is  a  symbol  (or  phrase)  that  always  refers  to  the  same  item 
of  data,  irrespective  of  where  it  occurs.  Examples  of  literals  are  ‘true’  and  ‘false’,  numerals, 
characters,  and  character  strings. 

The  denotational  semantics  of  literals  is  fairly  straightforward,  but  somewhat  tedious,  to  specify. 
We  have  already  seen  a  simple  example:  binary  numerals  (Section  2.3).  So  let  us  skip  most  of  the 
details  here.  A  skeleton  abstract  syntax  for  literals  is  given  in  Table  2.8. 

(Literal) 

L  ::=  true  |  false  |  N  \  C  \  CS 

(Numeral) 

N  ::=  unspecified 

(Character) 

C  ::=  unspecified 

(Character-String) 

CS  ::=  unspecified 

Table  2.8:  Syntax  for  literals 

For  the  denotations  of  ‘true’  and  ‘false’,  we  may  use  the  values  true  and  false  of  the  standard 
domain  T.  The  denotations  of  numerals  should  take  into  account  that  different  implementations 
generally  impose  different  bounds  on  the  magnitude  of  numbers,  and  on  the  accuracy  of  “real” 
numbers.  So  let  the  domain  of  numbers — together  with  the  associated  operations — be  a  parameter 
of  the  semantics.  The  same  goes  for  the  denotations  of  characters  (the  ordering  may  vary  between 
implementations)  and  strings  (their  length  may  be  bounded).  Let  us  leave  such  parameters  as 
unspecified  variables  in  the  semantic  description. 

For  example,  let  the  domains  Num,  Char,  and  String  be  unspecified  domain  variables,  together 
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with  various  variables  for  elements  of,  and  functions  on,  these  domains;  see  Table  2.9.  It  is  straight¬ 
forward  to  define  the  semantic  functions  introduced  in  Table  2.10  in  terms  of  the  given  elements 
and  functions.  The  details  are  omitted  here. 


Num 

= 

unspecified 

zero,  one 

G 

Num 

neg 

g 

Num  o — ►  Num 

sum,difF 

6 

(Num  0  Num)  o-*  Num 

prod,  div 

G 

(Num  0  Num)  o— ►  Num 

Char 

= 

unspecified 

ord 

G 

Char  o->  Num 

chr 

G 

Num  o->  Char 

String 

= 

unspecified 

str 

G 

Char*  o->  String 

chrs 

G 

String  o— *  Char* 

V 

= 

T  ®  Num  ©  Char  ©  String 

Table  2.9:  Domains  for  literals 


C  :  Literal  —  V 

Af  :  Numeral  -*■  Num 

C  :  Character  —  Char 

CS  :  Character-String  —  String 

Table  2.10:  Denotations  for  literals 

By  the  way,  the  domains  of  literal  denotations  are  generally  flat  (and  countable).  Note  in 
particular  that  the  finite  numerical  approximations  to  real  numbers  made  by  computers  should 
not  be  represented  by  values  related  by  the  computational  approximation  ordering  of  domains.  C: 
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once  an  approximate  real  number  has  been  computed,  further  computation  does  not  improve  the 
degree  of  approximation  of  that  number.  (Of  course,  a  program  may  indeed  compute  a  series  of 
approximate  numbers,  but  the  numbers  are  not  necessarily  increasingly-good  approximations  to 
some  particular  number.) 

2.5.2  Expressions 

Expressions  in  programming  languages  are  constructed  using  operators  and  (perhaps)  if-then-else 
from  primitive  expressions,  including  literals.  Abstract  syntax  for  some  typical  expressions  is  given 
in  Table  2.11.  (Further  expressions  are  considered  in  later  sections.) 

(Expression) 

E  ::=  L  |  MO  E\  J  E\  DO  E?  |  if  E\  then  £->  else  £3 

(Monadic-Operator; 

MO  |  - 

(Dyadic- Operator) 

DO  ::=  A  |  V  |  +  |  -  |  *  |  = 

Table  2.11:  Syntax  for  expressions 

We  take  the  denotations  of  expressions  to  be  elements  of  a  domain  EV  that  consists  of  truth- 
values,  numbers,  etc.,  representing  the  result  of  expression  evaluation.  The  domain  EV  is  a  -o-called 
'‘characteristic  domain”,  and  its  relation  to  other  characteristic  domains  introduced  in  later  sections 
can  give  valuable  insight  into  the  essence  of  the  described  programming  language.  For  now  we  let 
EV  contain  the  same  values  as  V,  i.e.,  the  values  of  literals  ater,  further  expressible  values  are 
introduced. 

We  are  now  ready  to  define  the  denotations  of  expressions  and  operators:  see  Table  2.12.  Note 
that  the  notational  conventions  introduced  at  the  end  of  Section  2.4  are  much  exploited  in  the 
semantic  equations.  For  instance,  in  the  equation  for  if-expressions,  there  is  an  application  of  a 
function  (At  G  T.  . . .)  to  an  argument  in  EV;  however,  T  is  a  summand  of  V.  which  is  isomorphic 
to  EV,  so  the  given  function,  /  say,  is  implicitly  extended  to  [/,  J-Num-EV, -l-char-EV. -Lstr,ng_Ev]  € 
(T  ~?  N um  Char  $  String)  —  EV,  and  then  composed  with  an  isomorphism  to  give  a  function  in 
EV  -  EV. 

Thus  the  denotation  of  an  erroneous  expression  such  as  ‘if  42  then. ..  else. ..  ’  is  _L.  The 
semantics  of  such  erroneous  expressions  is  actually  irrelevant,  provided  that  programs  containing 
them  are  deemed  illegal.  More  generally,  however,  it  might  be  better  to  avoid  representing  errors  by 
_L,  as  the  essential  use  of  _L  (in  later  sections)  is  to  represent  non-termination.  To  do  this  we  would 
have  to  introduce  special  elements  for  representing  errors  into  all  domains,  and  the  extra  notation 
for  specifying  the  treatment  of  errors  would  be  an  unwelcome  burden  in  the  semantic  equations. 


EV  =  V 


£  :  Expression  -*•  EV 
€[L  1  =  C[L\ 

E[  MO  £1  ]  =  MO[MO\(.£[E{\) 

£[  Ei  DO  E2  ]-VO[DO\{smish{£[Ei\1£[E2])) 

£[  if  Ei  then  £7  else  £3  ]  =  (Af  €  T.  ifttl en  £\Et,\  eise  £[£3]) 

MO:  Monadic-Operator  ~»(Vo-*V) 

MO\  -i  ]  =  Xt  e  T.  if  t  then  false  else  true 
MO[  —  ]  =  An  €  Num.  difF(zero,  n) 

VO:  Dyadic-Operator  —  (V®V©-*V) 

VO\  A  ]  =  A(<j  €  T,  t-i  £  T).  if  i  1  then  <2  else  false 

VO[  4-  ]  =  '.(raj  €  Num,  712  6  Num).  sum( 711,02) 

VO[  =  1  =  A(w!  €  V.uj  €  V).  (vi  =v  »a) 

Table  2.12:  Denotations  for  expressions 
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2.5.3  Constant  Declarations 

Identifiers  are  symbols  used  as  “tokens”  for  values.  In  programming  languages,  there  are  various 
constructs  which  introduce  identifiers  and  “bind”  them  to  values.  It  is  conventional  to  refer  to  the 
value  to  which  an  identifier  is  bound  as  the  value  “denoted”  by  the  identifier,  but  this  terminology 
is  a  bit  misleading:  the  denotation  of  an  identifier  is  the  identifier  itself  (or  rather,  an  element  of  a 
semantic  domain  corresponding  to  the  abstract  syntax  of  identifiers). 

Let  us  start  with  some  simple  “constant  declarations”,  whose  abstract  syntax  is  given  in  Ta¬ 
ble  2.13.  The  intended  effect  of  the  declaration  ‘val  I  *  E'  is  to  “bind”  /  to  the  value  of  E.  The 
construct  ‘let  CD  in  £”  determines  the  “scope”  of  such  “bindings”:  the  bindings  made  by  CD 
are  available  throughout  E — except  where  overridden  by  another  binding  for  the  same  identifier, 
since  ‘let’s  may  be  nested,  giving  a  “block  structure*  in  expressions.  In  ‘C£>i;  CD 2’,  the  scope 
of  the  bindings  introduced  by  CD\  includes  CDi .  The  phrase  ‘rec  CD ’  extends  the  scope  of  the 
declarations  in  CD  to  CD  itself,  making  them  “mutually- recursive”. 

(Constant-Declarations) 

CD  ::=  val  I  =  E  \  CDX ;  CD?  |  rec  CD 

(Expression) 

E  ::=  I  |  let  CD  in  E 

Table  2.13:  Syntax  for  constant  declarations 

In  the  semantics,  we  write  DV  for  the  domain  that  represents  the  values  “denotable”  by  identi¬ 
fiers.  DV  is  a  characteristic  domain,  like  EV.  In  real  programming  languages  there  are  sometimes 
values  that  are  expressible  but  not  denotable — numbers  in  Algol60,  for  instance.  Less  obviously, 
there  may  be  values  that  are  denotable  but  not  expressible — types  in  Pascal,  for  instance. 

“Environments”  are  used  to  represent  associations  between  identifiers  and  denoted  values.  The 
domain  of  environments,  together  with  some  basic  functions  on  environments,  is  defined  in  Ta¬ 
ble  2.14.  Ide  is  assumed  to  be  a  flat  domain  corresponding  to  the  abstract  phrase  sort  Identifier. 
The  element  T  €  0  is  used  to  indicate  the  absence  of  a  denoted  value.  (To  allow  the  presence  of  a 
denoted  value  to  be  tested,  we  would  have  to  lift  DV  to  DVX,  since  the  denoted  value  might  be  _L.) 
Notice  that  overlay(e,  e')  gives  precedence  to  e,  whereas  combine(e,  e')  =  combine(e\e)  is  intended 
for  uniting  the  bindings  of  disjoint  sets  of  identifiers. 

The  result  of  expression  evaluation  now  depends,  in  general,  on  the  values  bound  to  the  identi¬ 
fiers  that  occur  in  it.  This  dependence  is  represented  by  letting  the  denotation  of  an  expression  be  a 
function  from  environments  to  c-.pressible  values — which  requires  rewriting  the  semantic  equations 
previously  specified  for  expressions. 

Clearly,  an  appropriate  denotation  for  a  constant  declaration  is  a  function  from  environments  to 
environments.  But  there  is  a  choice  to  be  made:  should  the  resulting  environment  be  the  argument 
environment  extended  by  the  new  bindings?  or  just  the  new  bindings  by  themselves?  Let  us  choose 
the  latter,  which  gives  a  bit  more  flexibility,  exploited  in  later  sections. 
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Env 

= 

Ide  — »■  (DV  ©  0) 

void 

= 

XI  G  Ide.  in2  T 

G 

Env 

bound 

= 

XI  G  Ide.  Ae  G  Env.  [idov,  -L](e(/)) 

G 

Ide  — »  Env  — ►  DV 

binding 

= 

XI  G  Ide.  Av  G  DV.  XI'  G  Ide.  if  I  =id«  I'  then  in^v)  else  in2(T) 

G 

Ide  — ►  DV  — +  Env 

overlay 

= 

A(e  G  Env,e'  G  Env).  XI  G  Ide.  [idov,  Ax  G  0.  e'(/)](e(/)) 

G 

Env  x  Env  -*  Env 

combine 

= 

A(e  G  Env,  Ae'  G  Env).  XI  G  Ide.  [Ad  G  DV.  [_L,Ax  G  0.  d],Ax  G  0.  idov©o] 

(e(/))(e'(/)) 

G 

Env  x  Env  Env 

Table  2.14:  Notation  for  environments 


The  denotations  of  constant  declarations  and  of  the  related  expressions,  together  with  the 
modified  denotations  of  the  previously-specified  expressions,  are  defined  in  Table  2.15. 

The  semantics  of  recursive  declarations  makes  use  of  fixEnv,  which  gives  the  least  fixed  point 
of  the  function  in  Env  — *  Env  to  which  it  is  applied.  To  see  that  this  provides  the  appropriate 
denotations,  consider  CV[  rec  val  I  •  E  ](e).  From  the  semantic  equations  we  have 

CD\  rec  val  /  *  E  1(e)  = 

fix(Ae'  G  Env.  binding(/)(5[£,](overlay(e',  e)))) 

i.e.,  the  least  e'  G  Env  such  that 

e'  =  binding(/)(£[£’](overlay(e',  e))). 

Let  v  =  ^f[£'J(overlay(e/,e));  we  have 

v  =  ^[£'J(overlay(binding  I  v,e)) 

and  in  fa  :t 

v  =  fix(At/  G  EV.  flEKoverlayfbinding  I  v',e))). 

Notice  that  a  direct  circularity  in  the  recursive  declarations  gives  rise  to  1  as  a  denoted  value, 
eg., 
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DV  =  V 
EV  =  V 

CV  :  Constant-Declarations  -*  Env  — *•  Env 
CV[  val  /  ®  E  ]  =  Ae  €  Env.  binding  I(£[E\e) 

CV[  CD\\  Clh  ]  =  Ae  G  Env.  (Aei  6  Env.  overlay(CP[CZ?2](overlay(ei,e)),ei)) 

{CV[CDl  ]e) 

CD[  rec  CD  ]  =  Ae  G  Env.  fix(Ae'  G  Env.  CX>[CDj(overlay(e,,e))) 

£  :  Expression  -»  Env  — ►  EV 
£  I  /  ]  =  Ae  G  Env.  bound  I  e 

£\  l«t  CD  in  E  ]  =  Ae  €  Env.  ^[^(overiay^^ICDje^)) 

£{  L  ]  =  Ae  G  Env.  C[L] 

£\  MO  Ei  ]  =  Ac  €  Env.  MO[MO\{£[Ex\e) 

£{  Ex  DO  Ei  ]  =  Ae  G  Env.  VO[DO](smash(£.[Ex]e,£[E2]e)) 

£\  if  Ex  then  2%  else  E3  ]  =  Ae  G  Env.  (At  G  T.  if  t  then  £ [E2]e  else  £{E3]e) 
_ {S\Ex\e) _ 

Table  2.15:  Denotations  for  constant  declarations  and  expressions  (modified) 

CV\  rec  val  /  *  /  ]  =  binding  /  _L 

in  contrast  to  a  mere  “forward  reference”: 

CV[  rec  (val  I  -  val  /'  «  0)  ]  =  over!ay( binding  I'  0,  binding  70). 

The  most  interesting  case  is  when  the  sequence  of  environments  e'n  defined  by 

e'0  =  binding(/)(£[£](_L)) 

e'i  =  binding(/)(f{£'J(overlay(eo,e)) 

en+ 1  =  binding(/)(£[£'J(overlay(e(l,  e)) 
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is  strictly  increasing,  converging  to — but  never  reaching — the  limit  point  e'  =  |Jnen-  With  the 
expressions  considered  so  far,  it  is  not  possible  to  get  such  a  sequence;  but  it  becomes  possible 
when  function  abstractions  are  introduced,  as  in  the  next  section. 

2.5.4  Function  Abstractions 

“Functions”  in  programs  resemble  mathematical  functions:  they  return  values  when  applied  to 
arguments.  In  programs,  however,  the  evaluation  of  arguments  may  diverge,  so  it  is  necessary  to 
take  into  account  not  only  the  relation  between  argument  values  and  result  values,  but  also  the 
stage  at  which  an  argument  expression  is  evaluated:  straight  away,  or  when  (if)  ever  the  value  of 
the  argument  is  required  for  calculating  the  result  of  the  application. 

Various  programming  languages  allow  functions  to  be  declared ,  i.e.,  bound  to  identifiers.  Often, 
functions  may  also  be  passed  as  arguments  to  other  functions.  But  only  in  a  few  languages  is 
it  possible  to  express  functions  directly,  by  means  of  so-called  “abstractions”,  without  necessarily 
binding  them  to  identifiers.  (These  languages  are  generally  the  so-called  “functional  programming 
languages”.) 

The  syntax  given  in  Table  2.16  allows  functions  to  be  expressed  by  abstractions  of  the  form  ‘fun 
(val  7)  E'\  we  refer  to  ‘val  /’  as  the  “parameter  declaration”  of  the  abstraction  (further  forms 
of  parameter  declarations  are  introduced  later)  and  to  E  as  the  “body”.  Notice  that  constant  dec¬ 
larations  of  the  form  ‘val  I'  ■  fun  (val  7)  E'  resemble  “function  declarations”  in  conventional 
programming  languages;  recursive  references  to  V  in  E  are  allowed  when  the  declaration  is  prefixed 
by  ‘r«c\ 

The  phrase  'Ex^E?)'  expresses  the  application  of  a  function  to  an  argument,  with  the  “actual 
parameter”  E?  being  evaluated  before  the  evaluation  of  the  body  of  the  function  abstraction  is 
commenced — this  “mode”  of  parameter  evaluation  is  known  as  “call  by  value”.  (Functions  in 
programming  languages  are  usually  allowed  to  have  lists  of  parameters;  this  feature  is  omitted 
here,  for  simplicity.) 

(Expression) 

E  ::=  fun  {PD)  E  |  EX{E2) 

(Parameter- Declaration) 

PD  ::=  val  7 

Table  2.16:  Syntax  for  functions  and  parameter  declarations 

There  are  two  distinct  possibilities  for  the  scopes  of  declarations  in  relation  to  abstractions,  aris¬ 
ing  from  identifiers  which  occur  in  the  bodies  of  abstractions,  but  which  refer  to  outer  declarations. 
With  so-called  static  scopes,  the  scopes  of  declarations  extend  into  the  bodies  of  an  abstraction  at 
the  point  where  the  abstraction  is  introduced,  so  that  the  declaration  referred  to  by  an  identifier  is 
fixed.  With  dynamic  scopes,  the  body  of  an  abstraction  is  evaluated  in  the  scope  of  the  declarations 
at  each  point  of  application,  so  that  the  declaration  referred  to  by  an  identifier  in  an  abstraction 


body  tnav  vary — and  be  different  from  that  referred  to  with  static  scopes.  There  is  some  dispute 
in  the  programming  community  about  which  of  these  scope  rules  is  “better”.  Here,  the  semantic 
description  of  static  scopes  is  illustrated;  dynamic  scopes  are  only  marginally  more  complicated  to 
describe. 

The  domains  for  use  in  the  semantics  of  function  abstractions  are  specified  in  Table  2.17.  Notice 
that  the  definitions  of  DV  and  EV  supercede  the  previous  definitions.  (No  changes  are  needed  to  the 
semantic  equations  for  declarations  and  expressions  given  in  Table  2.12,  thanks  to  our  notational 
conventions  about  injections  and  extensions  related  to  sums.) 

F  =  (PVo-FV)x 
PV  =  V  ®  F 
FV  =  V 
DV  =  V  ©  F 
EV  =  V  ©  F 

£  :  Expression  -*  Env  -*  EV 
£[  fun  (.PD)  E  ]  = 

Ae  €  Env.  (up  o  strict)(Av  €  PV.  idFv(£[£'K°verlay(7?T>|[PD|u,  e)))) 

£[  ExiEi)  1  =  Ae  €  Env.  (down  o  idF)(£[£ile)(£[5ile) 

VV  :  Parameter-Declarations  — ►  PV  -*•  Env 
VV[  val  I  ]  =  Xv  €  PV.  binding  I v 

Table  2.17:  Denotations  for  functions  and  parameter  declarations 

To  model  abstractions  it  is  obvious  to  use  functions.  The  domains  consisting  of  parameter  values. 
PV,  and  function  result  values,  FV,  may  be  regarded  as  characteristic  domains.  Few  programming 
languages  allow  functions  to  be  returned  as  results  (and  some  even  forbid  functions  as  arguments). 

The  functions  corresponding  to  the  values  of  abstractions  are  taken  to  be  strict,  reflecting 
value-mode  parameter  evaluation:  X  represents  the  non-termination  of  an  evaluation,  and  the  non¬ 
termination  of  an  argument  evaluation  implies  the  non-termination  of  the  function  application. 
The  abstraction  values  are  lifted  so  that  an  abstraction  never  evaluates  to  X. 

Notice  that  the  domain  F  is  reflexive :  it  is  isomorphic  to  a  domain  that  (essentially)  includes  a 
domain  of  functions  from  F. 

The  semantic  equations  for  function  abstractions  are  given  in  Table  2.17.  Various  isomorphisms 
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are  left  implicit,  for  instance  that  between  DV  and  EV;  likewise,  some  injections  and  extensions 
related  to  sum  domains  are  omitted. 

An  alternative  mode  of  parameter  evaluation  is  to  delay  evaluation  until  the  parameter  is  used. 
This  mode  is  referred  to  as  “call  by  name”.  (The  main  difference  it  makes  to  the  semantics  of 
expressions  is  that  an  evaluation  which  doesn’t  terminate  with  value-mode,  may  terminate  when 
name-mode  is  used  instead.) 

Only  a  few  programming  languages  provide  name-mode  parameters.  Much  the  same  effect, 
however,  can  be  achieved  by  passing  a  (parameterless)  abstraction  as  a  parameter,  and  applying  it 
(to  no  parameters)  wherever  the  value  of  the  parameter  is  required. 

The  main  theoretical  significance  of  name-mode  abstractions  is  that  they  correspond  directly 
to  A- abstractions  in  the  A -calculus  of  Church  (see  [4]).  Consider  the  abstract  syntax  for  A-calculus 
expressions  given  in  Table  2.18.  The  axiom  of  so-called  “/3-conversion”  of  the  A-calculus  makes 
an  application  ‘(A/.  E)(E')'  equivalent  to  the  expression  obtained  by  substituting  E '  for  I  in  E 
(with  due  regard  to  static  scopes  of  A-bindings),  and  this  is  just  E  when  I  does  not  occur  in  E. 

(Expression) 

E  ::=  (A/.  E)  |  EiiE?)  \  I 

(Identifier) 

I  ::=  unspecified 

Table  2.18:  Syntax  for  A-expressions 

It  is  a  simple  matter  to  adapt  the  domains  that  were  used  to  represent  value-mode  abstractions, 
so  as  to  provide  a  denotational  semantics  for  the  A-calculus.  The  only  necessary  changes  are  to  let 
FV  include  F,  and  to  remove  the  restriction  of  F  to  strict  functions;  but  let  us  dispense  with  the 
lifting  as  well,  as  it  is  no  longer  significant.  The  presence  of  V  (in  FV)  ensures  that  the  solution 
to  the  domain  equations  is  non-trivial.  (The  standard  model  for  the  A-calculus  [18]  is  obtained  by 
taking  PV  =  FV  =  F,  leaving  essentially  F  =  F  —  F,  and  the  trivial  solution  has  to  be  avoided 
another  way.) 

The  denotations  for  the  A-calculus  are  specified  in  Table  2.19,  where  for  once  the  injections  and 
extensions  related  to  the  sum  domain  are  made  explicit  (although  the  isomorphisms  between  the 
left-  and  right-hand  sides  of  the  specified  domain  equations  are  still  omitted). 

The  standard  model  for  the  A-calculus  has  been  extensively  studied,  and  there  are  some  signif¬ 
icant  theorems  about  it.  Most  of  these  carry  over  to  the  denotations  defined  above.  First  of  all, 
there  is  the  theorem  that  the  semantics  does  indeed  model  /3-conversion: 

Proposition  33  For  any  A- expressions  ‘A I .  E’  and  E1 , 

S[  CM.  E)CE')  I  =  S[  IE'/ HE  J. 

Here  'IE' /HE'  is  the  proper  substitution  of  E1  for  free  occurrences  of  I  in  E:  the  identifiers  of 
A- abstractions  in  E  are  assumed  (or  made)  to  be  different  from  the  free  identifiers  in  c'. 
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F  =  PV  —  FV 


PV  =  V  ©  F 
FV  =  V  ©  F 
DV  =  V  ©  F 
EV  =  V  ©  F 

£  :  Expression  — *■  Env  -*•  EV 
£[  {XI.  E )  ]  = 

Ae  G  Env.  in2(Av  6  PV.  £[£'J(overlay(binding  Iv,e ))) 

£[  E\{Ev)  1  =  Ae  G  Env.  [±,idF](£[£x]e)(£[£2]e) 

Table  2.19:  Denotations  for  A-expressions 
The  key  to  proving  the  above  theorem  is: 

Lemma  34  (Substitution)  For  any  A -expressions  E,  E' ,  for  any  identifier  I,  and  for  any  e  G 
Env, 

£[  E  ](overlay(binding(/)(£[£/]e),e))  =  £[  IE'/F\E  ]e. 

The  following  theorem  implies  that  /3-reduction  is  sufficient  for  symbolic  computation  of  ap¬ 
proximations  to  any  desired  degree  of  closeness.  Let  A(E)  be  the  set  of  approximate  normal  forms 
of  E  (obtained  from  E  by  finite  sequences  of  /3-reductions,  followed  by  the  replacement  of  any 
remaining  redexes  by  an  expression  ‘ST  denoting  -L). 

Theorem  35  (Limiting  Completeness)  For  any  \~expression  E, 

SI  E]  =  \J{£[E'\\E'zA{E)}. 

The  original  proof  by  Wadsworth  [59]  involves  the  introduction  of  an  auxiliary  calculus  with  numer¬ 
ical  labels  forcing  all  reduction  sequences  to  terminate.  An  alternative  proof  is  given  by  Mosses  and 
Plotkin  [36]  by  introducing  an  “intermediate”  denotations!  semantics,  where  denotations  are  taken 
to  be  functions  of  an  argument  in  the  chain  domain  of  extended  natural  numbers  (i.e.,  with  oo): 
for  finite  arguments,  the  intermediate  semantics  gives  approximations,  corresponding  to  the  deno¬ 
tations  of  approximate  normal  forms;  the  standard  denotations  are  obtained  when  the  argument  is 
oo. 


81 


2.5.5  Variable  Declarations 

The  preceding  sections  dealt  with  expressions,  constant  declarations,  and  function  abstractions.  In 
conventional  programming  languages,  these  constructs  play  a  minor  role  in  comparison  to  state¬ 
ments  (also  called  “commands”),  which  operate  on  “variables”.  This  section  deals  with  the  seman¬ 
tics  of  variables;  statements  themselves  are  deferred  to  the  next  section. 

In  programs,  variables  are  entities  that  provide  access  to  stored  data.  The  assignment  of  a  value 
to  a  variable  has  the  effect  of  modifying  the  stored  data,  whereas  merely  inspecting  the  current 
value  of  a  variable  causes  no  modification. 

This  concept  of  a  variable  is  somewhat  different  from  that  of  a  variable  in  mathematics.  In 
mathematical  terms ,  variables  stand  for  particular  unknown  values — often,  the  arguments  of  func¬ 
tions.  These  variables  do  indeed  get  “assigned”  values,  e.g.,  by  function  application.  But  the  values 
thus  assigned  do  not  subsequently  vary:  a  variable  refers  to  the  same  value  throughout  the  term  in 
which  it  is  used.  In  fact  mathematical  variables  correspond  closely  to  identifiers  in  programming 
languages. 

Program  variables  may  be  simple  or  compound.  The  latter  have  component  variables  that  may 
be  assigned  values  individually;  the  value  of  a  compound  variable  depends  on  the  values  of  its 
component  variables. 

Consider  the  syntax  specified  in  Table  2.20.  The  variable  declaration  ‘var  I:  T'  determines  a 
“fresh”  variable  for  storing  values  of  the  “type”  T,  and  binds  I  to  the  variable.  Variable  declarations 
are  combined  by  ‘  VD\ ,  VDfi\  such  declarations  do  not  include  each  other  in  their  scopes  (although 
in  our  simple  example  language,  it  would  make  no  difference  if  they  did,  as  variable  declarations  do 
not  refer  to  identifiers  at  all).  The  types  ‘bool’,  ‘num’  are  for  declaring  simple  variables,  for  storing 
truth- values,  respectively  numbers;  the  type  ‘T[l.  .NY  is  for  declaring  compound  variables  that 
have  N  independent  component  variables  for  storing  values  of  type  T.  In  the  expression  ‘£i  [£2]”. 
Ei  is  supposed  to  evaluate  to  a  compound  variable,  v,  and  Ej  to  a  positive  integer,  n;  then  the 
result  is  the  nth  component  variable  of  v. 

(Variable-Declarations) 

VD  ::=  var  [ :  T  \  VDX ,  VD2 

(Type) 

T  ::=  bool  |  num  |  T  [1 . .  N~\ 

(Expression) 

_ E  ::=  EilEA _ _ 

Table  2.20:  Syntax  for  variable  declarations  and  types 

Types  are  used  for  two  nurposes  in  programming  languages:  to  facilitate  checking  that  programs 
are  well-formed,  prior  to  execution;  and  to  indicate  how  much  storage  to  allocate,  during  exe'  ution. 
Here,  we  are  only  concerned  with  the  dynamic  semantics  of  programs,  which — in  general— does  not 
involve  type  checking,  only  storage  allocation.  (Mitchell  [26]  provides  an  extensive  study  of  the 
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semantics  of  types.) 

“Stores”  are  used  to  represent  associations  between  simple  variables  and  their  values.  Simple 
variables  are  represented  by  “locations”  in  stores;  their  only  relevant  property  is  that  they  can  be 
distinguished  from  each  other.  Thus  a  simple  variable  identifier  gets  bound  to  a  location,  which  in 
turn  gives  access  to  the  current  value  stored  in  the  variable.  It  is  possible  for  two  identifiers  to  be 
bound  (in  the  same  scope)  to  the  same  location:  then  assignment  to  the  one  changes  the  value  of 
the  other.  Such  identifiers  are  called  “aliases”. 

Compound  variables  can  be  represented  by  values  with  variables  (ultimately,  locations)  as  com¬ 
ponents.  Whereas  assignment  to  distinct  simple  variables  is  independent,  distinct  compound  vari¬ 
ables  may  “share”  component  variables. 

The  domain  of  storable  values,  5V,  consists  of  those  items  of  data  that  can  be  stored  at  single 
locations.  It  may  be  considered  to  be  a  characteristic  domain. 

The  domain  of  (states  of)  stores,  S,  is  defined  in  Table  2.21,  together  with  some  basic  functions 
on  stores.  A  location  mapped  to  false  is  “free”,  and  a  location  mapped  to  true  is  “reserved”  but 
not  yet  “initialized”.  Notice  that  the  function  ‘location’  is  left  unspecified — it  is  supposed  to  select 
any  location  that  is  not  reserved  in  the  given  state.  It  is  usual  to  ignore  the  boundedness  cf  real 
computer  storage  in  denotational  semantics,  so  ‘location’  may  be  assumed  not  to  produce  _L  (unless 
applied  to  a  state  in  which  all  the  locations  have  somehow  been  reserved). 

Some  further  notation  concerned  with  compound  variables  is  specified  in  Table  2.22.  It  provides 
convenient  generalizations  of  the  basic  functions  on  stores.  LV  is  the  domain  of  all  variables;  RV 
is  the  domain  of  assignable  values.  (The  names  of  these  domains  stem  from  the  sides  of  the 
assignment  statement  on  which  variables  and  assignable  values  are  used:  “left”  and  “right”.)  They 
are  considered  to  be  characteristic  domains.  Usually,  as  here,  LV  has  Loc  .s  a  summand,  and  RV 
has  SV  as  a  summand. 

The  denotations  of  variable  declarations  and  types  are  given  in  Table  2.23.  It  is  convenient  to 
introduce  a  second  semantic  function  for  variable  declarations:  for  specifying  that  variables  are  no 
longer  accessible — when  exiting  the  scope  of  local  variable  declarations,  for  instance.  Formally,  the 
denotation  of  a  variable  declaration  VD  is  the  pair  (VD[V.D], VU\VD\). 

The  appropriate  denotations  for  expressions,  declarations,  etc.,  are  now  functions  of  stores,  as 
well  as  environments.  Whether  expression  evaluation  should  be  allowed  to  affect  the  store — known 
as  “side-effects” — is  controversial:  some  languages  (such  as  C)  actually  encourage  side-effects  in 
expressions,  but  allow  the  order  of  evaluation  of  expressions  to  be  specified;  others  make  the  order 
of  evaluation  of  expressions  “implementation-dependent”,  so  that  the  semantics  of  programs  that 
try  to  exploit  side-effects  in  expressions  becomes  nondeterministic.  Here,  let  us  forbid  side-effects, 
for  simplicity.  Thus  denotations  of  expressions  may  be  functions  from  environments  and  stores  to 
expressible  values — there  is  no  need  to  return  the  current  store,  as  it  is  unchanged. 

We  must  modify  the  semantic  equations  for  expressions,  now  that  the  denotations  of  expressions 
take  stores  as  arguments.  But  first,  note  that  in  various  contexts,  there  is  an  implicit  “coercion” 
when  the  expression  evaluation  results  in  a  variable,  but  the  current  value  of  the  variable  is  required. 
Such  contexts  include  operands  of  operators  and  conditions  of  if-then-else  expressions.  Very  few 
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s 

= 

Loc  -  (SV  ©  T) 

Loc 

= 

C  ©  Loc 

empty 

= 

XI  €  Loc.  false 

G 

S 

reservation 

= 

XI  6  Loc.  A s  £  S. 

(A l'  6  Loc.  if  /  =loc  V  then  true  else  s(/')) 

e 

Loc  — ►  S  — ►  S 

freedom 

= 

XI  6  Loc.  As  6  S. 

(A l'  6  Loc.  if  /  =i.oc  l'  then  false  else  s(l')) 

g 

Loc  — *  S  — ►  S 

store 

= 

XI  e  Loc.  Xv  €  SV.  As  G  S. 

(A/'  €  Loc.  if  /  =Loc  l'  then  v  else  s(l')) 

g 

Loc  -  SV  -  S  —  S 

stored 

= 

XI  €  Loc.  As  6  S.  [ids v,-L](*(0) 

G 

Loc  —  S  —  SV 

location 

= 

unspecified 

€ 

5  — *■  Loc 

allocation 

= 

As  €  S.  (XI  g  Loc.  (/reservation  /s))( location 

G 

S  — +  Loc  x  S 

Table  2.21:  Notation  for  stores 
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LV 

RV 

allocations 


freedoms 


component 

assign 


assigned 


Loc  ©  LV* 
SV  ©  RV* 


=  A(/  G  S  — *  LV  x  S,n  G  Nx). 
if  n  =  0  then  A 3  G  S.  (T,  3)  else 
(A(/  G  LV,3  G  S).  (A(/*  G  LV*,s'  G  S).  ((/,/*),  3)) 
(allocations(/,  n  —  1)  s))  o  f 

G  (S  ->  LV  x  S)  x  Nx  -4  S  -  LV  x  S 

=  A(/  G  LV  —►  S  — ►  S,n  G  Nx). 
if  n  =  0  then  A /*  G  0.  id?  else 
A (/  G  LV,  /*  G  LV*).  freedoms( /,  n  -  1)  /*  0  / / 

6  (LV  —  S  —  S)  x  N  j.  -  LV  —  S  —  S 

=  An  G  Nx-  ifn  =  1  then  on!  else  component(n  -  1)  o  on2 

G  N±  — ►  LV*  -»  LV 

=  [store, 

[XI  G  0.  Aw  G  0.  ids, 

A (/  G  LV,/*  G  LV*).  A(w  G  RV,w*  G  RV*). 
assign  i*  w*  o  assign  /  v]] 

G  LV  — ►  RV  — ►  S  — *•  S 

=  [stored, 

[XI  G  0.  A 3  G  S.  (T,  3), 

A(/G  LV,/*  G  LV-).  (A(wG  RV,3  G  S). 

(A(w*  G  RV*,3'G  S).  ((w,w*),3')) 

(assigned  /*  3))  o  assigned  /]] 

G  LV  —  S  —  RV  x  S 


Table  2.22:  Notation  for  compound  variables 
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SV  =  T  ©  Num 

VV  :  Variable-Declarations  -*•  S  -»  (Env  x  S) 

VD[  var  /:  T  ]  =  (A (/  G  L V,s  6  S).  (binding  7/,a))oT[r] 

VD[  VZ>i,  VD2  ]  =  (A(ei  G  Env,3i  6  S).  (A(e2  G  Env,s2  €  S).  (combine(e1,e2),s2)) 

(VD[ra2]Sl)) 

o  VD[VDil 

VI/  :  Variable-Declarations  — ►  Env  -*•  So->S 
V7/[  var  I:  T  ]  =  Ae  G  Env.  TZ/[T](bound  Je) 

VZVf  .  VD2  1  =  Ae  G  Env.  W/J  VD2]e‘o  VZ/[  V^Je 

T  :  Type  -  S  —  LV  x  S 

T[  bool  ]  =  allocation 

T[  num  J  =  allocation 

T[  TZ1..N1  J  =  allocations(T[rj,vV[^I) 

TU  :  Type  —  LV  o—  S  0—  S 
77V [  bool  ]  =  freedom 
77V[  num  J  =  freedom 

TU[  TZI..N1  ]  =  freedom s(TU[T\,Af{N\) 

Table  2.23:  Denotations  for  variable  declarations  and  types 
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programming  languages  insist  that  the  programmer  use  an  explicit  operator  on  a  variable  in  order 
to  obtain  its  current  value. 

In  practical  programming  languages,  various  coercions  are  allowed.  A  good  example  is  the 
coercion  from  a  parameterless  function  to  the  result  of  applying  the  function,  allowed  in  Algol60 
and  Pascal.  Of  course,  a  static  semantic  analysis  could  use  contextual  information  to  recognize 
such  coercions  and  replace  them  by  explicit  operators.  But  in  general,  it  is  easy  enough  to  deal  with 
coercions  directly  in  the  dynamic  semantics — although  languages  like  Algol68  and  Ada  allow  so 
many  coercions  that  it  may  then  be  preferable  to  define  the  dynamic  semantics  on  the  basis  of  an 
intermediate  abstract  syntax  where  the  coercions  have  been  made  explicit. 

It  is  convenient  to  introduce  a  secondary  semantic  function  for  expressions,  71,  that  corresponds 
to  ordinary  evaluation  followed  by  coercion  (when  possible).  The  modifications  to  our  previous 
specification  are  straightforward;  the  result  is  shown  in  Table  2.24,  together  with  the  semantic 
equation  for 

2.5.6  Statements 

The  statements  (or  commands)  of  programming  languages  include  assignments  of  values  to  vari¬ 
ables,  and  constructs  to  control  the  order  in  which  assignments  are  executed.  Some  typical  syntax 
for  statements  is  given  in  Table  2.25. 

In  the  assignment  statement  lEi  :•  E?',  the  left-hand  side  E\  must  evaluate  to  a  variable  and  £7 
must  evaluate  to  an  assignable  value.  The  executions  of  the  statements  in  ‘Si ;  S2’  are  sequenced 
(from  left  to  right!)  and  ‘skip’  corresponds  to  an  empty  sequence  of  statements.  Conditional 
execution  is  provided  by  ‘if  E  than  S\\  whereas  ‘while  E  do  S\  iterates  Si  as  long  as  £  is 
true.  The  block  ‘begin  VD ;  Si  end’  limits  the  scope  of  the  variable  declarations  in  VD  to  the 
statements  Si,  so  that  the  variables  themselves  are  “local”  to  the  block,  and  may  safely  be  re-used 
after  the  execution  of  Si — assuming  that  “pointers”  to  local  variables  are  not  permitted.  Let  us 
defer  consideration  of  the  remaining  statements  in  Table  2.25  until  later  in  this  section. 

The  denotations!  semantics  of  statements  is  quite  simple:  denotations  are  given  by  functions, 
from  environments  and  stores,  to  stores.  The  bottom  store  represents  the  non-termination  of 
statement  execution,  and  the  functions  are  strict  in  their  store  argument,  reflecting  that  non- 
termination  cannot  be  “ignored”  by  subsequent  statements. 

We  are  now  ready  to  define  the  denotations  of  statements:  see  Table  2.26.  Notice  that  the 
use  of  VU  improves  the  abstractness  of  statement  denotations:  without  it,  the  states  produced  bv 
statement  denotations  would  depend  on  the  local  variables  allocated  in  inner  blocks. 

The  following  proposition  is  a  direct  consequence  of  the  semantic  equations,  using  the  unfolding 
property  of  ‘fix'. 

Proposition  36 

5}  while  E  do  S\  J  =  S[  if  E  then  (Si ;  while  E  do  Sj)  J. 
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F  =  (PV<^So-*FV)x 
PV  =  V  ©  F  ®  LV 
F V  =  V 

DV  =  V  ©  F  ©  LV 
EV  =  V  ©  F  ©  LV 

'll :  Expression  -*  Env  -*•  S  -*•  RV 

n[  e  ]  =  Ae  G  Env.  A s  6  S.  [idRv,-L,A/  €  LV.  assigned  /s](£[£]es) 

£  :  Expression  -*  Env  -*■  S  ->  EV 

£[  L  ]  =  Ae  G  Env.  As  €  S.  C[L ] 

£[  MO  Ex  ]  =  Ae  G  Env.  As  €  S.  MO[MO](H[Ei]e  s) 

£[  Ei  DO  Ej  ]  =  Ae  G  Env.  As  G  S.  'DO\DO\(smas\\('R\E\\e  s,H[E-2]e  s)) 

£\  if  E\  then  Ei  else  £3  ] = 

Ae  6  Env.  As  €  S.  (A  t  €  T.  iff  then  £[Eh\e  s  else  £[£3Je  s ) 

(Tl[Ei]es) 

£\  I  ]  =  Ae  G  Env.  As  6  S.  bound  I e 

£[  let  CD  in  E  J  =  Ae  G  Env.  As  G  S.  £[£](overlay(CP[CD]es,e)s) 

£[  fun  ( PD )  E  ]  = 

Ae  G  Env.  As  G  S.  (up  o  strict  )(Au  G  PV.  idFV  0  £[£’](overlay('PP[F,Z?Ju.  e))) 
£[  Ei(E-2 )  ]  =  Ae  G  Env.  As  G  S.  (down  0  \d?)(£[Ei\e s)(£\Ei\e  s)  s 

£[  Ei  [£2]  ]  =  Ae  G  Env.  As  G  S.  component(£[£1Jes,72[£2jes) 

CD  :  Constant-Declarations  —  Env  -*  S  —  Env 

CV[  val  /  ■  E  ]  =  Ae  G  Env.  As  G  S.  binding  I (£\E\e  s) 

CV[  CDi ;  CD?  J  =  Ae  G  Env.  As  G  S. 

(Aei  G  Env.  overlay(CI>[CD2](overlay(ei,e))s,ei)) 
{CV[CDi\e3) 

CD\  rec  CD  J  =  Ae  G  Env.  As  G  S.  fix(Ae'  G  Env.  CP[CZ)](overlaviV.  e))  s) 

- - 55 - 

Table  2.24:  Denotations  for  expressions  (modified) 


(Statements) 

S  ::=  E\  :»  £?  \  S\\  S?  |  skip  | 

if  E  then  5i  |  while  E  do  Si  | 
begin  VD-,  S\  end  | 
stop  |  I:  S\  |  goto  I 

Table  2.25:  Syntax  for  statements 
S  :  Statements  — ►  Env  S  o->  S 

S[  E\  :•  E?  ]  =  Ae  E  Env.  As  E  S.  (XI  6  LV.  An  E  RV.  strict  assign  /  v  s) 

(£[Ei]es)(lllE2]es) 

«S“[  Si ;  $2  ]  =  Ae  E  Env.  S[S2]e  o  S[Si]e 
S[  skip  ]  =  A«  E  Env.  ids 

<S[  if  E  then  S\  ]  =  Ae  E  Env.  As  E  S.  (At  E  T.  if  t  then  S[Si]e  s  else  s) 

(?Z[£]es) 

while  E  do  S\  ]  =  Ae  E  Env.  fix(Ac  E  S  £>-*•  S.  As  E  S. 

(At  E  T.  if  t  then  c(Sf5i]e  s)  else  s) 

(*[£!«)) 

5[  begin  VD\  S\  end  ]  = 

Ae  E  Env.  (A(e'  E  Env,s  E  S).  VU[  VZ?](e/)(«S[5il(overlay(e',  e))(s))) 
o  VV[VD]e 

Table  2.26:  Denotations  for  statements  (direct) 

Now  let  us  consider  the  statement  ‘stop’,  whose  intended  effect  is  that  when  (if  ever)  the 
execution  of  a  statement  reaches  it,  the  execution  of  the  enclosing  program  is  terminated — without 
further  changes  to  the  state,  just  as  if  control  had  reached  the  end  of  the  program  normally.  We 
may  say  that  ‘stop’  causes  a  jump  to  the  end  of  the  program.  (For  now,  let  programs  be  simply 
statements.  The  semantics  of  programs  is  considered  further  in  Section  2.5.8.) 

However,  with  the  denotations  for  statements  used  so  far,  we  have  (for  any  statement  Si  and 
e  E  Env): 

S[  Si;  while  true  do  skip  Je  =  fix(idc_c)  0  *S[5i]e 

=  ±c°‘5[SiJe  —  J_c 

which  is  in  conflict  with  the  intended  equivalence  of  ‘stop;  while  true  do  skip’  to  ‘stop’. 

In  order  to  deal  with  ‘stop’,  we  clearly  have  to  change  the  denotation  of  ‘Si ;  S2’.  There  are 
two  main  techniques  available  for  modeling  jumps  such  as  ‘stop’:  “flags”,  and  “continuations". 
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The  technique  using  flags  is  to  use  a  domain  of  denotations  such  as  Env  — *  S  o—  (S  ©  S).  Then 
a  resulting  store  in  (say)  the  first  summand  may  represent  normal  termination,  and  a  result  in  the 
second  summand  may  represent  that  ‘stop’  has  been  executed,  so  that  no  further  statements  are 
to  be  executed.  Thus  we  would  have 

<S[  Si;  S2  ]  =  [S[S2]e,in2]  o  (S[Si]e) 

It  is  easy  to  imagine  the  analogous  changes  that  would  be  needed  to  the  semantic  equations  for 
the  other  statements,  to  take  account  of  the  two  possibilities  for  resulting  stores.  (No  changes 
would  be  needed  to  the  semantic  equations  for  expressions  and  declarations,  as  they  do  not  involve 
statements.) 

The  alternative  technique  for  dealing  with  jumps  is  to  let  denotations  of  statements  take  contin¬ 
uations  as  arguments.  The  continuation  argument  represents  the  semantics  of  what  would  be  the 
“rest  of  the  program”,  if  the  statement  were  to  terminate  normally.  In  the  denotation  of  each  state¬ 
ment,  it  is  specified  whether  to  use  the  continuation  argument,  or  to  ignore  it  and  use  a  different 
continuation,  such  as  the  empty  continuation,  which  represents  a  jump  to  the  end  of  the  program. 
A  divergent  iterative  statement  just  never  gets  around  to  using  the  argument  continuation  (and 
strictness  is  no  longer  needed  to  reflect  the  preservation  of  divergence). 

In  the  rest  of  this  section,  the  use  of  the  continuations  technique  is  illustrated,  albeit  briefly. 

Let  the  characteristic  domains  (DV,EV,  etc.)  be  as  usual.  The  domain  of  statement  continu¬ 
ations  may  be  taken  to  be  simply  the  domain  S  — ►  S  of  functions  on  stores.  For  uniformity,  let 
all  denotations  be  functions  of  continuations.  The  continuations  of  expressions  are  functions  from 
values  to  ordinary  continuations,  those  for  declarations  are  functions  from  environments  to  continu¬ 
ations,  etc.  (Auxiliary  operations,  such  as  assign,  could  be  changed  to  take  continuation  arguments 
as  well,  if  desired.)  Such  a  semantics  is  called  a  “continuation  semantics”;  our  previous  examples 
of  semantics  are  called  “direct”. 

Sufficient  semantic  equations  to  illustrate  the  technique  of  continuations  are  given  in  Table  2.27. 
(The  semantic  functions  of  the  continuation  semantics  are  marked  with  primes  to  distinguish  them 
from  the  corresponding  direct  semantic  functions.)  Notice  the  order  of  composition  in  the  semantic 
equation  for  ‘Si ;  S^’:  the  opposite  to  that  in  direct  sem;  oticC 

The  transformation  from  direct  to  continuation  semantic  straightforward.  It  may  seem  quite 
obvious  that  the  transformation  gives  an  “equivalent”  semantics,  but  it  is  non-trivial  to  prove 
such  results:  the  relations  to  be  established  between  the  domains  of  the  direct  and  continuation 
semantics  have  to  be  defined  recursively,  and  then  shown  to  be  well-defined  and  “inclusive”  [44], 

Continuations  were  originally  introduced  to  model  the  semantics  of  general  ‘goto’-statements. 
Consider  again  the  syntax  given  in  Table  2.25.  An  occurrence  of  a  labeled  statement  ‘7:  S\'  may 
be  regarded  as  a  declaration  that  binds  /,  where  the  scope  of  this  binding  is  the  smallest  enclosing 
block  ‘begin  VD ;  Si  end’. 

The  execution  of  ‘goto  /’  is  intended  .to  jump  to  the  statement  labeled  by  I.  It  may  be  seen 
to  consist  of 
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c  =  s  -  s 


€' :  Expression  — *•  Env  -» (EV  -*■  C)  -*■  C 

TV  :  Expression  -*•  Env  — ►  (RV  -<■  C)  -*  C 

W  :  Variable-Declarations  -*•  Env  -*•  (Env  -*•  C)  -*•  C 

S' :  Statements  -*•  Env  —■  C  -*•  C 

S'[  E\  :*  Ei  ]  =  Ae  £  Env.  Ac  £  C. 

€’[Ex\e  (XI  £  LV.  K'[Ei]e(\v  £  RV.  c  o  (assign  / u))) 

S'[  Si;  S2  ]  =  Ac  6  Env.  Ac  €  C.  <S'[5i]|e (^[S^Jcc) 

5'[  skip  ]  =  Ae  €  Env.  Ac  €  C.  c 

5'[  while  E  do  Si  ]  =  Ac  €  Env.  fix(A<j  e  C  -+  C.‘  Ac  €  C. 

7V[E\e{\t  G  T.  if  t  then  5'[Si]e  (5(c))  else  c)) 

5'[  stop  ]  =  Ac  €  Env.  Ac  €  C.  ids 

5'[  goto  I  J  =  Ac  g  Env.  Ac  £  C.  bound  I  e 

CD'  :  Statements  -*  Env  — ►  C  -*  Env  * 

Table  2.27:  Denotations  for  statements  (continuations) 

1.  the  termination  of  enclosing  statements  (including  procedure  calls)  up  to  the  innermost  ‘begin 
VD ;  Si  end’  that  includes  the  declaration  of  the  label  /;  then 

2.  the  execution  of  those  parts  of  Si  that  follow  after  the  label  /;  and  finally 

3.  the  normal  termination  of  ‘begin  VD ;  Si  end’,  provided  that  no  further  jump  prevents  this. 

(Actually,  this  analysis  suggests  a  direct  semantics  using  flags,  where  label  identifiers  are  bound 
to  pairs  consisting  of  “activation  levels”  and  direct  statement  denotations:  continuations  are  not 
actually  necessary  for  the  denotational  description  of  ‘goto’-statements.) 

Letting  C  be  a  summand  of  D V,  the  value  bound  to  I  by  ‘J:  Si  is  <S'lSi]ec,  where  c  is  the 
continuation  argument  of  «S'[  I :  Si  Je.  So  assuming  that  the  environment  argument  e  includes 
this  binding,  the  denotation  of  the  ‘goto’-statement  merelv  replaces  its  argument  continuation  bv 
the  continuation  bound  to  /,  as  specified  in  Table  2.27.  The  declarative  component  of  statement 
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denotations  may  be  expressed  by  a  semantic  function  CD'  whose  definition  involves  a  fixed  point, 
which  reflects  that  the  continuations  denoted  by  label  identifiers  in  a  block  may  be  mutually- 
recursive.  The  details  are  somewhat  tedious;  let  us  omit  them  here,  as  unrestricted  jumps  to  labels 
are  not  allowed  in  most  modern  high-level  programming  languages. 

Note  that  continuations  give  possibilities  for  jumps  that  are  even  less  “disciplined”  than  those 
provided  by  the  ‘goto’  statement:  a  general  continuation  need  have  no  relation  at  all  to  the  context 
of  where  it  is  used! 

Continuations  have  been  advocated  as  a  standard  technique  for  modeling  programming  lan¬ 
guages  (along  with  the  use  of  environments  and  states)  in  preference  to  direct  semantics.  Although 
the  adoption  of  this  policy  would  give  a  welcome  uniformity  in  models,  it  would  also  make  the 
domains  of  denotations  for  simple  languages  (e.g.,  the  A-calculus)  unnecessarily  complex — and,  at 
least  in  some  cases,  the  introduction  of  continuations  would  actually  reduce  the  abstractness  of 
denotations. 

The  popularity  of  continuations  seems  to  be  partly  due  to  the  accompanying  notational 
convenience — especially  that  the  order  in  which  denotations  of  sub-phrases  occur  in  semantic  equa¬ 
tions  corresponds  to  the  order  in  which  the  phrases  are  intended  to  be  executed:  left  to  right. 
(Perhaps  direct  semantics  would  be  more  popular  if  function  application  and  composition  were 
to  be  written  “backwards”.)  Another  notational  virtue  of  continuations  is  that  “errors”  can  be 
handled  neatly,  by  ignoring  the  continuation  argument  and  using  a  general  error-continuation. 

2.5.7  Procedure  Abstractions 

Procedure  abstractions  are  much  like  function  abstractions.  The  only  difference  is  that  the  body 
of  a  procedure  abstraction  is  a  statement,  rather  than  an  expression. 

By  the  way,  many  programming  languages  do  not  allow  functions  to  be  expressed  (or  declared) 
directly:  procedures  must  be  used  instead.  The  body  of  the  procedure  then  includes  a  special 
statement  that  determines  the  value  to  be  returned  (in  Algol60  and  Pascal,  this  statement 
looks  like  an  assignment  to  the  procedure  identifier!). 

Syntax  for  procedure  abstractions  is  given  in  Table  2.28.  As  with  functions,  we  consider  pro¬ 
cedures  with  only  a  single  parameter;  but  now  some  more  modes  of  parameter  evaluation  are 
introduced. 

(Expression) 

E  ::=  proc  ( PD )  S\ 

(Parameter- Declaration) 

PD  ::=  var  /:  T  \  I:  T 

(Statements) 

S  ::=  EitEj) 

Table  2.28:  Syntax  for  procedures 
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The  procedure  abstraction  ‘proc  (var  /:  T)  S\  requires  its  parameter  to  evaluate  to  a  vari¬ 
able,  and  /  denotes  that  variable  in  the  body  S\.  This  mode  of  parameter  evaluation  is  usually 
known  as  “call  by  reference”,  but  here  we  refer  to  it  as  “variable-mode”  parameter  evaluation. 

The  procedure  abstraction  ‘proc  (.1:  T)  Si’  requires  its  parameter  to  be  coercible  to  an 
assignable  value;  then  a  local  variable  is  allocated  and  initialized  with  the  parameter  value,  and 
I  denotes  the  variable  in  the  body  S\.  This  mode  of  parameter  evaluation  .s  usually  known  as 
“call  by  value”,  but  it  should  not  be  confused  with  the  value- mode  parameter  evaluation  that  was 
considered  for  function  abstractions:  that  did  not  involve  any  local  variable  allocation.  Let  us  refer 
to  this  mode  as  “copy-mode”  parameter  evaluation. 

The  procedure  call  statement  ‘£1  (£2) '  executes  the  body  of  the  procedure  abstraction  produced 
by  evaluating  E\,  passing  the  argument  obtained  by  evaluating  the  parameter  E 2. 

Note  that  execution  of  the  procedure  body  may  have  an  effect  on  the  state,  by  assignment  to 
a  non-local  variable.  With  variable-mode  parameters,  there  is  also  the  possibility  of  modifying  the 
state  by  assigning  to  the  formal  parameter  of  the  abstraction;  whereas  with  copy-mode,  such  an 
assignment  merely  modifies  the  local  variable  denoted  by  the  parameter  identifier.  Note  also  that 
variable-mode  allows  two  different  identifiers  to  denote  the  same  variable,  i.e.,  “aliasing”. 

Now  for  the  formal  semantics  of  procedures.  The  denotations  of  procedure  expressions,  param¬ 
eter  declarations,  and  statements  are  defined  in  Table  2.29. 

The  procedure  call  syntax  ‘£i( E?)'  does  not  give  any  indication  of  the  mode  of  parameter 
evaluation,  so  we  leave  it  to  the  denotation  of  the  parameter  declaration  to  perform  any  required 
coercion  of  the  parameter  value.  An  alternative  technique  is  to  let  the  evaluation  of  the  parameter 
expression  £2  depend  on  a  mode  component  of  the  value  of  the  procedure  expression  £1. 

By  the  way,  the  second  semantic  function  for  parameter  declarations,  VU,  is  analogous  to  the 
semantic  function  VU  for  variable  declarations,  explained  in  Section  2.5.5. 

2.5.8  Programs 

As  discussed  in  Section  2.3,  the  semantics  of  an  entire  program  should  be  a  mathematical  represen¬ 
tation  of  the  observable  behaviour  when  it  is  executed  by  computers  (but  ignoring  implementation- 
dependent  details).  Typically,  this  behaviour  involves  streams  of  “input”  and  “output”. 

By  definition,  the  input  of  a  program  is  the  information  that  is  supplied  to  it  by  the  user;  the 
output  is  the  information  that  the  user  gets  back.  However,  it  is  important  to  take  into  account  not 
only  what  information  is  supplied,  but  also  when  the  supply  takes  place.  The  main  distinction  in 
conventional  programming  languages  is  between  so-called  “batch”  and  “interactive”  input-output. 

With  batch  input,  all  the  input  to  the  program  is  supplied  at  the  start  of  the  program.  The 
input  may  then  be  regarded  as  stored,  in  a  “file”.  Batch  output  is  likewise  accumulated  in  a  file, 
and  only  given  to  the  user  when  (if  ever)  the  program  terminates. 

On  the  other  hand,  interactive  input  is  provided  gradually,  as  a  stream  of  data,  while  the 
program  is  running;  the  program  may  have  to  wait  for  further  input  data  to  be  provided  before  it 
can  proceed.  Similarly,  interactive  output  is  provided  to  the  user  while  the  program  is  running,  as 
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P  =  (PV  0->  S  0-»  S)_L 
PV  =  V©F©LV©P 
DV  =  V©F©LV©P 
EV  =  V©F©LV©P 

S  :  Expression  -►  Env  -*•  S  -♦  EV 

€[  proc  (.PD)  S  1  = 

Ae  6  Env.  up(strictAv  €  PV. 

(A(e'  €  Env,  3  6  S).  •Pi/[PD]e/(tS[5](overlay(e,,e)))) 
o  Vj[ PD)e) 

VV  :  Parameter-Declaration  -*  PV  -*•  S  -+  Env  x  S 

VV\  val  I:  T  ]  =  Xve  P V.  A3  €  S.  (binding  I  v,  s) 

W[  var  I:  T  J  =  XI  €  LV.  A3  €  S.  (binding  Il,s) 

VV[  I:  T  ]  =  Xv  e  PV.  A3  €  S. 

(Xv'  6  RV.  (A (/'  €  LV,  s'  €  S).  (binding  IV,  assign  l'  v'  s')) 
(T[T]s)) 

([A/  €  LV.  assigned  /3,idRV,-L,-L](v)) 

VU  :  Parameter-Declaration  -*  Env  —  S  -*  S 

VU\  val  I  ]  =  Ae  €  Env.  ids 

VU\  var  I:  T  ]  =  Ae  6  Env.  ids 

VU[  /:  T  J  =  Ae  G  Env.  TU[T\{ bound  It) 

S  :  Statements  —  Env  -»  S  o-»  S 

*S(  E\(,E?)  J  =  Ae  6  Env.  A3  €  S.  (down  0  idp)(^[£’i]e  3)(5[£,2]e  3)  3 
Table  2.29:  Denotations  for  procedures 
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soon  as  it  has  been  determined. 

Note  that  interactive  input-output  allows  (later)  items  of  input  to  depend  on  (earlier)  i^ems  of 
output.  For  instance,  input  may  be  stimulated  by  an  output  “prompt”. 

We  may  regard  batch  input-output  as  merely  a  special  case  of  interactive  input-output:  the 
program  starts,  and  then  immediately  reads  and  stores  the  entire  input;  output  is  stored  until  the 
program  is  about  to  terminate,  and  then  the  entire  output  is  given  to  the  user. 

The  essential  difference  between  batch  and  interactive  input-output  shows  up  in  connection  with 
programs  that  (on  purpose)  may  run  “for  ever”:  batch  input-output  cannot  reflect  the  semantics 
of  such  programs.  Familiar  examples  are  traffic-light  controllers,  operating  systems,  and  screen 
editors.  These  programs  might,  if  allowed,  read  an  infinite  stream  of  input,  and  produce  an  infinite 
stream  of  output.  (They  might  also  terminate,  in  response  to  particular  input — or  “spontaneously”, 
when  an  error  occurs.)  Moreover,  once  an  item  of  output  has  been  produced,  it  cannot  be  revoked 
by  the  program  (e.g.,  the  traffic-light  controller  cannot  “undo”  the  changing  of  a  light). 

Consider  the  abstract  syntax  for  input-output  statements  and  programs  specified  in  Table  2.30. 
There  is  nothing  in  the  given  syntax  that  indicates  whether  the  semantics  of  input-output  is 
supposed  to  be  batch  or  interactive.  Let  us  consider  both  semantics.  We  restrict  items  of  input 
and  output  to  be  truth-values  and  numbers,  i.e.,  the  same  as  SV. 

(Program) 

P  ::=  prog  S 

(Statements) 

5  ::=  read  €  j  write  E 

Table  2.30:  Syntax  for  programs 

For  batch  semantics,  we  may  take  the  representation  of  streams  to  be  finite  lists.  The  semantic 
equations  for  programs,  and  for  read  and  write  statements,  are  given  in  Table  2.31:  our  previous 
semantic  equations  for  other  statements  have  to  be  modified  to  take  account  of  the  extra  arguments, 
but  the  details  are  omitted  here. 

The  following  proposition  confirms  that  batch  output  is  not  observable  when  program  execution 
doesn’t  terminate: 

Proposition  37 

V{  prog  while  true  do  write  0  ]  =  V[  prog  while  true  do  skip  ]  =  x. 

The  reason  for  this  is  that  the  denotation  of  the  non-terminating  while-loop  is  given  by  the  least 
fixed  point  of  a  stnct  function. 

Now  for  interactive  input-output  semantics  for  the  same  language.  See  Table  2.32.  Let  us 
first  change  from  SV*  to  SV$,  which  represents  infinite  (and  partial)  streams.  (The  only  difference 
between  SV*  and  the  standard  domain  construction  SV°°  is  that  the  latter  allows  X  components  to 
be  followed  by  non-X  components.)  This  change  by  itself  would  not  make  any  substantial  difference 
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In  =  SV* 

Out  =  SV* 

V  :  Program  -*■  (In  o~*  Out) 

V[  prog  Si  1  =  Ai  G  In.  on3(S[Si](void)(empty,i,T)) 

S  :  Statements  -♦  Env  -+  (S  ®  In  ®  Out)  o— (S  ®  In  ®  Out) 

S[  read  E  ]  =  Ae  G  Env.  A(s  G  S,i  G  ln,o  G  Out). 

(XI  G  Loc.  [i.,A(v  G  SV,  i'  G  In).  smash(store  ly«,i',o)]) 

(f[£le«)(i) 

S[  write  E  ]  =  Xe  G  Env.  A (3  G  S,t  G  ln,o  G  Out). 

(Av  G  SV.  smash(a,  t, extend  do)) 

extend  =  Au  G  SV.  [Ai  G  0.  (v,  T), 

A(v'  G  SV,o  G  Out),  (v',  extend  co)] 

G  SV  —  Out  —  Out 

Table  2.31:  Denotations  for  programs  (batch) 

to  the  semantics  of  programs:  input-output  would  still  be  batch,  and  the  above  proposition  would 
still  hold. 

The  essential  change  is  to  ensure  that  an  item  of  output  becomes  incorporated  in  the  program’s 
semantics,  irrevocably,  as  soon  as  the  corresponding  ‘write’  statement  is  executed.  There  are  var¬ 
ious  ways  of  achieving  this  property:  in  particular,  by  using  continuations.  Reverting  temporarily 
to  continuation  semantics  (see  Section  2.5.6)  we  define  the  interactive  semantics  of  programs  as 
shown  in  Table  2.32. 

Proposition  38 

V\  prog  while  true  do  write  0  ]  ^ 

V\  prog  while  true  do  skip  ]. 

It  is  instructive  to  see  how  to  deal  with  interactive  input-output  without  using  continuations. 
Consider  the  domain  10  defined  in  Table  2.33,  and  let  statement  denotations  be  given  by  functions 
from  environments  and  stores  to  10.  Each  element  of  10  represents  a  sequence  of  readings  and 
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sv* 

=  SV®  SV*X 

In  = 

sv* 

Out 

=  sv* 

C  = 

S  — ►  In  — ►  Out 

V  : 

Program  In  -»  Out 

V'[ 

prog  5i  ]  =  5'[5il(void)(As  G  S.  Ai  G  In. 

T)(empty). 

S'  : 

Statements  -*•  Env  -*  C  -*•  C 

S'[ 

read  E  ]  =  Xe  G  Env.  Ac  G  C. 

S'\E\e  (XI  G  loc.  As  G  S.  A(t> 

G  SV,  t  G  In),  (c  0  store  l  *•)  3  i)) 

S'l 

write  E  J  =  Ae  G  Env.  Ac  G  C. 

1Z'[E]e(\v  G  SV.  As  G  S.  Ai 

G  In.  smash(w,  up(cs  t))) 

Table  2.32:  Denotations  for  programs  (interactive,  continuations) 


writings,  ending  (if  at  all)  with  a  state.  This  might  not  seem  particularly  abstract,  but  notice 
that  statement  denotations  must  reflect  the  order  in  which  readings  and  writing  occur,  since  the 
semantics  of  a  program  in  In  — »  Out  reveals  this  information  when  applied  to  partial  inputs. 

The  semantic  equations  specified  in  Table  2.33  illustrate  this  technique.  The  fixed  point  used 
in  the  denotation  of  'Si ;  S?'  essentially  corresponds  to  going  through  the  input  and  output  corre¬ 
sponding  to  Si  until  a  final  state  is  reached,  and  then  starting  S2;  similarly  for  programs.  It  can 
be  shown  that  interactive  output  is  modeled. 

Now  consider  “piping”  the  output  of  one  program  into  the  input  of  another,  as  expressed  by 
a  program  construct  ‘Pi  |  P2\  With  interactive  input-output,  both  programs  can  be  started 
simultaneously — but  the  execution  of  the  second  program  may  have  to  be  suspended  to  await  input 
that  has  yet  to  be  output  by  the  first  program.  The  start  of  the  first  program  could  be  delayed 
until  the  second  program  actually  tries  to  read  from  its  input  (if  ever),  and  then  execution  could 
alternate  between  the  two  programs,  according  to  the  input-output.  All  these  possibilities  are 
expressed  by  the  same  semantic  equation: 

V[  Pl  I  Pi  ]  =  V[P2\oV[Px]. 

With  batch  input-output,  the  second  program  does  not  start  until  the  first  one  terminates. 
As  with  statements,  such  sequential  execution  can  be  modeled  by  composition  of  strict  functions 
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10  =  S  ®  (SV  O-  10) j.  0  (SV  ®  I0x). 


V  :  Program  —  In  -*  Out 

V[  prog  5i  ]  =  f!x(A h  e  10  — ►  In  — ►  Out. 

[As  £  S.  A i  £  In.  i  , 

A/£  SV  -  10.  A(w  £  SV,  i  £  In).  h(f(v))(i), 
X(v  £  SV,io  e  10).  A i  £  In.  (w,  up(/i(io)(i)))]) 
(S[Sx](void)(empty)) 


S  :  Statements  -♦  Env  -*  S  o->  10 

5[  E\  :*  Ei  J  =  Ae  £  Env.  As  £  S. 

(A/  £  Loc.  Aw  £  SV.  inx (store  l  vs)) 
MExlesKIllEAes) 

5[  read  E  ]  =  Ae  £  Env.  As  £  S. 

(XI  £  Loc.  in2(Au  £  SV.  up(inx(store  l  v  s)))) 
(£[E\)es) 

5[  write  E  ]  =  Ae  £  Env.  As  £  S. 

(Aw  €  SV.  in3(w,up(ini(s)))) 

(H[E7\es) 

5[  skip  ]  =  Ae  £  Env.  ids 

5[  5i :  52  ]  =  Ae  £  Env.  As  £  S. 

fix';  <7  £  1 0  — *■  10. 

[5[52]e, 

A/  £  SV  —  \0.gcf, 

X(v  £  S V ,  io  £  10).  (w,  up(jr( to)))]) 
(JlSiJes) 


Table  2.33:  Denotations  for  programs  (interactive,  direct) 
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(the  semantic  equation  for  piped  programs  remains  the  same,  assuming  V  is  defined  as  for  batch 
input-output). 

2.5.9  Nondeterminism 

The  final  technique  illustrated  in  this  chapter  is  the  use  of  power  domains  to  model  nondeterministic 
constructs  such  as  “guarded  commands”  and  interleaving. 

For  our  purposes  here,  it  is  not  necessary  to  understand  the  actual  structure  of  power  domains. 
All  that  we  need  to  know  about  a  power  domain  is  that  it  is  equipped  with  a  continuous  union 
operation  (associative,  commutative,  and  absorptive),  a  continuous  singleton  operation,  and  that 
functions  on  domains  can  be  extended  pointwise  to  power  domains.  (Recall  the  notation  adopted 
in  Section  2.4.  We  use  only  the  natural,  or  convex,  power  domain;  the  other  power  domains  do  not 
accurately  reflect  the  possibility  of  divergence.) 

Consider  the  syntax  for  guarded  statements  given  in  Table  2.34.  The  intention  of  ‘£  ->  Si' 
is  that  the  statement  Si  is  guarded  by  £  and  may  only  be  executed  if  E  evaluates  to  true.  So 
far,  this  resembles  ‘if  E  than  Si’;  the  difference  is  that  guarded  statements  may  be  “united” 
by  the  construct  iG\  □  G 2,  whose  execution  consists  of  executing  precisely  one  of  the  guarded 
statements  in  Gi  and  G2.  Notice  that  (when  E  evaluates  to  a  truth- value)  the  guarded  statement 

E  ->  Si  D  ~>E  ->  S2 

expresses  a  deterministic  choice  between  Si  and  S2,  whereas 
true  ->  Si  □  true  ->  S2 
expresses  a  nondeterministic  choice. 

(Guarded-Statements) 

G  ::=£->  S  |  Gi  □  G2 

(Statements) 

S  ::=  if  G  fi  |  do  G  od 

Table  2.34:  Syntax  for  guarded  statements 

Both  the  statements  ‘if  G  fi’  and  ‘do  G  od’  involve  the  execution  of  G ,  when  possible.  Let 
us  regard  the  former  as  equivalent  to  an  empty  statement  when  it  is  not  possible  to  execute  G. 
With  the  latter,  the  execution  of  G  is  repeated,  as  many  times  as  possible. 

We  take  the  denotations  for  statements  to  be  functions  from  environments  and  stores  to  elements 
of  the  power  domain  Ss;  these  elements  represent  the  non-empty  sets  of  possible  states  resulting  from 
statement  execution  (possibly  including  _L).  The  denotations  of  guarded  statements  are  similar,  but 
T  represents  the  empty  set  of  states.  The  semantic  equations  are  specified  in  Table  2.35.  (We  do 
not  need  to  change  the  denotations  of  expressions  and  declarations,  which  are  still  deterministic.) 


Q  :  Guarded-Statements  -*  Env  -*•  S  o->(0  ®  S11) 

G[  E  ->  Si  ]  =  \e  £  Env.  strictAs  G  S. 

(At  G  T.  if  t  then  ir.2(S[Si]e  s)  else  inj  T )(7?[£']e  5) 

Q[  G\  □  <J2  1  =  Ae  6  Env.  strictAs  G  S. 

[Ai  G  0.  i^o®s8’ 

Ap!  £  S11.  [Ax  G  0.  in2(pi), 

Ap2  6  Sb.  in2(pi  U  Pi)\[(G[G\\e  s)(Q[G-i]e  s) 

S  :  Statements  -+  Env  — «•  S  o— *■  Sh 

5[  if  G  i i  ]  =  Ae  £  Env.  strictAs  £  S. 

(Ax  £  0.  idsa](^[<Sr]e  3) 

S[  do  G  od  ]  =  Ae  G  Env.  fix(Ac  €  S  o-+  S11.  strictAs  £  S. 
_ [Ax  GO.  M,ext(c)](g[C]e3)) _ 

Table  2.35:  Denotations  for  guarded  statements 

As  an  illustration  of  the  semantic  equivalence  that  is  induced  by  the  above  definitions,  consider 
the  two  statements  Sj,  S2  shown  in  Table  2.36.  It  is  obvious  that  S?  has  the  possibility  of  not 
terminating;  what  may  be  less  obvious  is  that  Si  has  precisely  the  same  possibilities: 

Proposition  39 

S[SX]  =  S[S2]. 

Thus  both  statements  have  the  possibility  of  terminating  with  the  variable  ‘y’  having  any  (non¬ 
negative)  value — or  of  not  terminating.  The  infinite  number  of  possibilities  arises  here  from  the 
iteration  of  a  choice  between  a  finite  number  of  possibilities:  the  possibility  of  non-termination 
cannot  be  eliminated  (c.f.  Konig’s  Lemma). 


X 

=  0; 

x  :-  0; 

y 

-  0; 

0 

N 

do 

N 

A 

1 

O 

II 

H 

:=  1 

do  x=0  ->  x 

=  1 

□ 

t*> 

A 

O 

N 

H 

:*  y+1 

□  x=0  ->  y 

*  y+1 

od 

□  true  ->  do 

true  ->  skip  od 

od 

Table  2.36:  Examples  of  guarded  statements  Si,  S2 


However,  one  could  imagine  having  a  primitive  statement  with  an  infinite  number  of  possibilities, 
excluding  non-termination.  E.g.,  consider  ‘randomize  E\  which  is  supposed  to  set  a  variable  E 


100 


to  some  arbitrary  integer.  Here  we  understand  “arbitrary”  to  mean  just  that  the  value  chosen  is 
completely  out  of  the  control  of  the  program — it  is  implementation-dependent.  (Thus  a  particular 
implementation  might  always  choose  zero,  or  the  successor  of  the  previous  choice.  Classes  of 
genuinely-random  implementations  could  be  considered  as  well.) 

It  is  important  to  note  that  our  domain  of  statement  denotations  above  does  not  contain  any 
element  that  can  be  used  for  the  denotation  of  an  .ilways-terminating  ‘randomize’  statement.  In 
fact  any  attempt  to  express  such  a  set  as 

as  an  element  of  Nx11  always  ends  up  by  including  $-!.}•  as  well. 

So  let  us  omit  further  consideration  of  randomizing  statements,  and  proceed  to  illustrate  a  tech¬ 
nique  known  as  “resumptions”,  which  is  useful  for  giving  a  denotational  semantics  for  concurrent 
processes. 


2.5.10  Concurrency 

The  language  constructs  considered  so  far  in  this  chapter  come  from  conventional  programming 
languages,  designed  to  be  implemented  sequentially.  Several  modern  programming  languages  have 
constructs  for  expressing  so-called  “concurrent  processes”,  and  may  be  implemented  on  a  “dis¬ 
tributed  system”  of  computers  (or  on  a  single  computer  that  simulates  a  distributed  system). 
Typically,  the  processes  are  executed  asynchronously,  and  they  interact  by  sending  messages  and 
making  “rendezvous". 

In  the  denotational  semantics  of  concurrent  systems,  the  concurrent  execution  steps  of  different 
processes  are  usually  regarded  as  “interleaved”.  Although  interleaving  is  a  rather  artificial  concept 
when  dealing  with  physically-distributed  systems  (due  to  the  lack  of  a  universal  time  scale)  it  is  not 
generally  possible  to  distinguish  the  possible  behaviours  of  proper  concurrent  systems  from  their 
interleaved  counterparts — at  least,  not  unless  the  observer  of  the  behaviours  is  distributed  too. 

The  final  example  of  this  chapter  deals  with  a  very  simple  form  of  concurrency:  interleaved 
statements.  The  syntax  of  these  statements  is  given  in  Table  2.37. 

(Statements) 

S  ::=  Si  1 1  S2  |  <  S  > 

Table  2.37:  Syntax  for  interleaved  statements 

The  intention  with  the  statement  ‘Si  II  S2’  is  that  Si  and  S2  are  executed  concurrently  and 
asynchronous'y.  If  Si  and  S2  use  the  same  variables,  the  result  of  their  concurrent  execution  may 
depend  on  the  order  in  which  the  “steps”  of  Si  are  executed  in  relation  to  those  of  S ?,  i.e.,  on  the 
interleaving.  Let  us  assume  that  assignment  statements  are  single,  “indivisible"  steps  of  execution, 
so  the  state  does  not  change  during  the  evaluation  of  the  left-  and  right-hand  sides.  The  construct 
‘<  Si  >’  makes  the  execution  of  any  statement  Si  an  indivisible  step  (sometimes  called  a  “critical 
region”). 


101 


Note  that  when  Si  and  $2  are  “independent”  (e.g.,  when  they  use  different  variables)  an  execu¬ 
tion  of  ‘Si  II  S2’ gives  the  same  result  as  the  execution  of ‘Si ;  S2’,  or  of ‘S2 ;  Si’;  but  in  general 
there  are  other  possible  results. 

Now  consider  statements 

51  :  x  :*  1 

52  x  :*  0;  x  :*  x+i. 

With  all  our  previous  denotations  for  statements,  we  have  S[Si]  =  SfSjJ.  But  when  statements 
include  ‘Si  II  S?’,  we  expect 

S[  Sx  1 1  Si  1  ?  SI  Si  II  S2  J 

since  the  interleaving  ‘x  :■  0;  x  :»  1;  x  :■  x+1’  of  Si  with  S2  sets  x  to  2,  whereas  the  inter¬ 
leaving  of  ‘x  :■  1’  with  itself  does  not  have  this  possibility. 

Thus  it  can  be  seen  that  the  compositionality  of  denotational  semantics  forces  S[Si]  ^  S[S2] 
when  concurrent  statements  are  included.  The  appropriate  denotations  for  statements  are  so- 
called  “resumptions”,  which  are  rather  like  segmented  (“staccato”)  continuations.  A  domain  of 
resumptions  is  defined  in  Table  2.38.  The  semantic  function  for  statements,  S,  maps  environment 
directly  to  resumptions,  which  are  themselves  functions  of  stores. 

Consider  p  =  S[SiJes.  It  represents  the  set  of  possible  results  of  executing  the  first  step  of  S\. 
An  element  ini(s')  of  this  set  corresponds  to  the  possibility  that  there  is  only  one  step,  resulting  in 
the  state  s'  (although  this  “step”  might  be  an  indivisible  sequence  of  steps).  An  element  in2(up  r,s’) 
corresponds  to  the  result  of  the  first  step  being  am  intermediate  state  s',  together  with  a  resumption 
r  which,  when  applied  to  s'  (or  to  some  other  state)  gives  the  set  of  possible  results  from  the  next 
step  of  Si,  and  so  on. 

Resumptions  provide  adequate  denotations  for  interleaved  statements,  as  the  semantic  equa¬ 
tions  in  Table  2.38  show.  However,  these  denotations  are  not  particularly  abstract:  e.g..  we  get 
S[  skip  J  ^  S[  skip;  skip  ],  even  though  the  two  statements  are  clearly  interchangeable  in 
any  program.  It  is  currently  an  open  problem  to  define  fully  abstract  denotations  for  concurrent 
interleaved  statements  (using  standard  semantic  domain  constructions). 

The  technique  of  resumptions  can  also  be  used  for  expressing  denotations  of  communicating 
concurrent  processes  (with  the  “store”  component  representing  pending  communications). 

We  have  finished  illustrating  the  use  of  the  main  descriptive  techniques  of  Denotational  Seman¬ 
tics:  environments,  stores,  strictness,  flags,  continuations,  power  domains,  and  resumptions.  The 
various  works  referenced  in  the  following  bibliographical  notes  provide  further  illustrations  of  the 
use  of  these  techniques,  and  show  how  to  obtain  denotations  for  many  of  the  constructs  to  be  found 
in  “real”  programming  languages. 


102 


R  =  So->(S©(Rx®S))s 


S  :  Statements  -»  Env  -*■  R 

5[  E\  :*  Ev  ]  =  Ae  G  Env.  strictAs  G  S. 

(A/  G  LV.  At;  G  RV.^  store  /  v  sj)(£[£i]e  3)(7^[£^]e  s) 

SI  Sii  S2  ]  =  Ae  €  Env.  fix(A/  G  R  — »  R.  Ar  G  R. 

ext[«S[S2]e, 

A(/€Rx,^6S).  (f(r'),s')]  or) 

(5[5,]e) 

5[  skip  ]  =  Ae  G  Env.  strictAs  €  S.  $«}• 

S[  Sr  II  S2  1  =  Ae  e  Env.  fix(Aj7  6  (R  x  R)  -*  R. 

A(ri  G  R,  r2  6  R).  strictAs  G  S. 

(ext[r2,A(r,1  G  Rx,-»'  €  S).  (ff(r'1,r2),s')](rl(s)))U 
(ext(ri,A(r^  G  Rx,s'  G  S).  (g(r:,  r'2),  s')](r2(s)))) 
(5I51le)(<S[51]e) 

si  <  S\  >  ]  =  Ae  6  Env.  fix(A/i  G  R  — *  R.  Ar  G  R. 

ext[Aa  G  S.  {aj, 

A(r'GR^'GS).  W)]°r) 

_ QS{5iJ«) _ 

Table  2.38:  Denotations  for  interleaved  statements 
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2.6  Bibliographical  Notes 

This  final  section  refers  to  some  published  works  on  Denotational  Semantics  and  related  topics, 
and  indicates  their  significance. 

2.6.1  Development 

The  development  of  Denotational  Semantics  began  with  the  paper  “Towards  a  Formal  Semantics” 
[52],  written  by  Christopher  Strachey  in  1964  for  the  IFIP  Working  Conference  on  Formal  Language 
Description  Languages.  The  paper  introduces  compositionally-defined  semantic  functions  that  map 
abstract  syntax  to  “operators”  (i.e.,  functions),  and  it  makes  use  of  the  fixed-point  combinator.  Y , 
for  expressing  the  denotations  of  loops.  It  also  introduces  (compound)  L-values  and  R-values,  in 
connection  with  the  semantics  of  assignment  and  parameter-passing.  The  treatment  of  identifier 
bindings  follows  Landin’s  approach  [21]:  identifiers  are  mapped  to  bound  variables  of  A-abstractions. 

Strachey’s  paper  “Fundamental  Concepts  of  Programming  Languages”  [53]  provides  much  of 
the  conceptual  analysis  of  programming  languages  that  underlies  their  denotational  semantics. 

The  main  theoretical  problem  with  Strachey’s  early  work  was  that,  formally,  denotations  were 
specified  using  the  type-free  A-calculus,  for  which  there  was  no  known  model.  In  fact  Strachey  was 
merely  using  A-abstractions  as  a  convenient  way  of  expressing  functions,  rather  than  as  a  formal 
calculus.  However,  the  fixed-point  combinator  Y  was  needed  (for  obtaining  a  compositional  seman¬ 
tics  for  iterative  constructs,  for  instance).  Because  Y  involves  self-application,  it  was  considered  to 
be  “paradoxical”:  it  could  be  interpreted  operationally,  but  it  could  not  be  regarded  as  expressing 
a  function.  By  1969,  Dana  Scott  had  become  interested  in  Strachey’s  ideas.  In  an  exciting  col¬ 
laboration  with  Strachey,  Scott  first  convinced  Strachey  to  give  up  the  type-free  A-calculus;  then 
he  discovered  that  it  did  have  a  model,  after  all.  Soon  after  that,  Scott  established  the  Theory 
of  Semantic  Domains,  providing  adequate  foundations  for  the  semantic  descriptions  that  Strachey 
had  been  writing. 

The  original  paper  on  semantic  domains  by  Scott  [46]  takes  domains  to  be  complete  lattices 
(rather  than  the  epos  used  nowadays).  Domains  have  effectively-given  bases;  Cartesian  product, 
(coalesced)  sum,  and  continuous  function  space  are  allowed  as  domain  constructors;  and  solutions 
of  domain  equations  are  found  as  limits  of  sequences  of  embeddings.  A  domain  providing  a  model 
for  self- application  (and  hence  for  the  A-calculus)  is  given,  and  a  recursively-defined  domain  for 
the  denotations  of  storable  procedures  is  proposed.  (For  references  to  subsequent  presentations  of 
domain  theory,  see  [18].) 

In  a  joint  paper  [48],  Scott  and  Strachey  present  what  is  essentially  the  approach  now  known  as 
Denotational  Semantics  (it  was  called  “Mathematical  Semantics”  until  1976).  The  paper  establishes 
meta-notation  for  defining  semantic  functions,  and  uses  functional  notation — rather  than  the  A- 
calculus — for  specifying  denotations.  Here,  for  the  first  time,  denotations  are  taken  to  be  functions 
of  environments,  following  a  suggestion  of  Scott.  The  abstract  syntax  of  finite  programs  is  a  set 
of  derivation  trees,  although  it  is  pointed  out  that  this  set  could  be  made  into  a  domain:  then 
semantic  functions  are  continuous,  and  their  existence  is  guaranteed  by  the  fixed  point  theorem 
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(see  also  [47],  where  partial  and  infinite  programs  are  considered). 

The  notion  of  “characteristic  domains”  was  introduced  by  Strachev  in  [54],  where  characteristic 
domains  are  given  for  Algol60  and  for  a  pedagogical  language  (PAL). 

The  use  of  continuations  in  denotational  semantics  was  proposed  by  Christopher  Wadsworth, 
and  reported  in  a  joint  paper  with  Strachey  [55].  The  present  author  was  one  of  the  first  to  exploit 
the  technique,  in  a  denotational  description  of  Algol60  [28]. 

By  the  mid-1970’s,  sufficient  techniques  had  been  developed  for  specifying  the  denotational 
semantics  of  any  conventional  (sequential)  programming  language.  Moreover,  John  Reynolds  [44] 
and  Robert  Milne  [22]  had  devised  a  way  of  proving  the  equivalence  of  denotational  descriptions 
that  involve  different  domains  (e.g.,  direct  and  continuation  semantics  for  the  same  language). 
Wadsworth  had  shown  the  relation  between  the  computational  and  denotational  semantics  of  the 
A-calculus  [59]  (see  also  [36]).  The  present  author  had  constructed  a  prototype  “semantics  imple¬ 
mentation  system”  (SIS),  for  generating  implementations  of  programming  languages  directly  from 
their  denotational  descriptions  [29,  30,  31].  Strachey’s  inspiration  was  sorely  missed  after  his  un¬ 
timely  death  in  1975;  but  there  was  confidence  that  denotational  semantics  was  the  best  approach 
to  programming  language  semantics,  and  that  it  would  be  a  routine  matter  to  apply  it  to  any  real 
programming  language. 

Then  the  increasing  interest  in  concurrent  systems  of  processes  led  to  the  development  of  pro¬ 
gramming  languages  with  non-deterministic  constructs.  An  early  treatment  by  Robin  Milner  [25] 
introduced  a  technique  using  so-called  “oracles”,  but  did  not  give  sufficiently  abstract  denotations: 
for  instance,  non-deterministic  choice  was  not  commutative.  Then  Gordon  Plotkin  showed  how  to 
define  power  domains  [40].  The  introduction  of  power  domains  required  domains  to  be  epos,  rather 
than  complete  lattices.  Moreover,  for  domains  to  be  closed  under  power  domain  constructions,  the 
epos  had  to  be  restricted  to  be  so-called  SFP  objects:  limits  of  sequences  of  finite  epos  (equivalent 
to  the  bifinite  epo’s,  see  [18]).  Much  of  Plotkin’s  paper  is  devoted  to  establishing  the  SFP  frame¬ 
work.  Also,  the  technique  of  “resumptions”  is  introduced,  and  used  to  define  the  denotations  for 
some  simple  parallel  programs. 

Mike  Smyth  gave  a  simple  presentation  of  Plotkin’s  power  domains  [49]  (and  introduced  a 
“weak”  power  domain).  Matthew  Hennessy  and  Plotkin  together  defined  a  category  of  “non- 
deterministic”  domains  [20],  and  showed  that  the  (Plotkin)  power  domain,  D6,  of  a  domain  D  is 
just  the  free  continuous  semi-lattice  generated  by  D.  They  also  introduced  a  tensor  product  for  non- 
deterministic  domains,  and  obtained  full  abstractness  for  a  simple  (although  somewhat  artificial) 
parallel  programming  language.  Krzysztof  Apt  and  Plotkin  [3]  related  the  Plotkin  power  domain 
to  operational  semantics;  they  showed  that  Smyth’s  weak  power  domain  (of  states)  corresponds  to 
Dijkstra’s  predicate  transformers.  Plotkin  [41]  generalized  power  domains  to  deal  with  countable 
non-determinism.  Samson  Abramsky  has  shown  [l]  that  the  Plotkin  power  domain  gives  fully 
abstract  denotations  when  observable  behaviour  is  characterized  by  classes  of  finite  experiments. 
There  has  also  been  work  on  power  domains  using  complete  metric  spaces  [2]. 

Despite  all  the  above  works,  it  is  debatable  whether  the  denotational  treatment  of  concurrency 
is  satisfactory.  There  are  difficulties  with  getting  reasonable  abstractness  of  denotations  when 


105 


using  resumptions.  Moreover,  the  use  of  power  domains  gives  an  unwelcome  notational  burden. 
In  contrast,  Structural  Operational  Semantics  (illustrated  in  [24])  extends  easily  from  sequential 
languages  to  concurrency. 

Another  problem  with  the  applicability  of  Denotational  Semantics  concerns  the  pragmatic  as¬ 
pects  of  denotational  descriptions.  For  “toy”  languages,  it  is  quite  a  simple  matter  to  “lay  the 
domains  on  the  table”  (following  [54]),  and  to  give  semantic  equations  that  define  appropriate  (but 
not  necessarily  fully  abstract)  denotations.  However,  the  approach  does  not  scale  up  easily  to 
“real”  programming  languages,  which  (unfortunately)  seem  to  require  a  large  number  of  complex 
domains  for  their  denotational  semantics.  Partly  because  the  semantic  equations  depend  explicitly 
on  the  domains  of  denotations,  it  can  be  extremely  difficult  to  comprehend  a  large  denotational 
description. 

A  related  problem  is  that  it  is  not  feasible  to  re-use  parts  of  the  description  of  one  language 
(Pascal,  say)  in  the  description  of  another  language  (MODULA2,  for  instance).  Analogous  problems 
in  software  engineering  were  alleviated  by  the  introduction  of  “modules”.  Denotational  Semantics 
has  no  notation  for  expressing  modules.  In  fact  if  the  definitions  of  the  domains  of  denotations  were 
to  be  encapsulated  in  modules,  it  would  not  be  possible  to  express  denotations  using  A-notation 
in  the  semantic  equations:  one  would  have  to  use  auxiliary  operations,  defined  in  the  modules,  for 
expressing  primitive  denotations  and  for  combining  denotations.  Thus  it  seems  that  a  high  degree 
of  modularity  is  incompatible  with  (conventional)  denotational  semantics. 

An  aggravating  factor,  concerning  the  problem  of  (writing  and  reading)  large  denotational 
descriptions,  may  be  that  the  intimate  relation  between  higher-order  functions  on  domains  and 
computational  properties  is  not  immediately  apparent.  (For  example,  with  non-strict  functions, 
arguments  may  not  need  to  be  evaluated.)  It  is  difficult  for  the  non-specialist  to  appreciate  the 
abstract  denotations  of  programming  constructs. 

The  effort  required  to  formulate  a  denotational  semantics  for  a  real  programming  language  is 
reflected  by  the  lack  of  published  denotational  descriptions  of  complete,  real  programming  lan¬ 
guages.  Efforts  have  been  made  for  SNOBOL  [56],  Algol60  [28],  Aigol68  [22],  Pascal  [58], 
and  Ada  [11].  In  general,  these  descriptions  make  some  simplifying  assumptions  about  the  pro¬ 
gramming  language  concerned;  they  also  omit  the  definitions  of  various  “primitive”  functions,  and 
use  numerous  notational  conventions  whose  formal  status  is  somewhat  unclear.  (Of  course,  much 
the  same — and  other — criticisms  could  be  made  of  alternative  forms  of  semantics.) 

Hope  for  the  future  of  denotational  semantics  lies  in  the  recent  popularization  of  two  languages 
that  have  been  designed  with  formal  (denotational)  semantics  in  mind:  Standard  ML  [19],  and 
Scheme  [43].  Although  the  denotational  descriptions  of  these  languages  are  not  used  formally  as 
standards  for  implementations,  they  do  show  that  it  is  possible  to  give  complete  descriptions  of 
useful  languages. 
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2.6.2  Exposition 

There  are  several  expository  works  that  explain  the  basic  notions  of  Denotational  Semantics,  and 
give  examples  of  the  prevailing  techniques  for  choosing  denotations: 

Bob  Tennent  [57]  provides  a  basic  tutorial  introduction,  containing  a  semantic  description  of 
Reynold’s  experimental  language  Gedanken  and  a  useful  bibliography. 

The  epic  work  by  Milne  and  Strachey  [23],  completed  by  Milne  after  Strachey’s  death,  con¬ 
tains  careful  discussions  of  many  techniques  for  choosing  denotations,  including  less  abstract  “non¬ 
standard”  denotations.  The  examples  given  are  related  to  ALGOL68.  It  is  a  valuable  reference  for 
further  study  of  Denotational  Semantics. 

Joe  Stoy’s  book  [50]  is  partly  based  on  Strachey’s  lectures  at  Oxford;  consequently,  scant  at¬ 
tention  is  paid  to  the  syntactic  constructs  of  later  programming  languages,  such  as  Pascal.  The 
foreword  by  Scott  gives  an  detailed  appreciation  of  Strachey  and  his  work. 

The  book  by  Mike  Gordon  [16]  takes  an  engineering  approach:  it  does  not  explain  foundations 
at  all.  The  techniques  illustrated  are  adequate  for  the  description  of  most  Pascal-like  programming 
languages. 

The  introductory  book  on  Denotational  Semantics  by  Dave  Schmidt  [45]  includes  a  rather 
comprehensive  description  of  domain  theory  (including  power  domains).  The  book  covers  a  number 
of  incidental  topics,  such  as  semantics-directed  compiler  generation,  and  there  is  a  substantial 
bibliography. 

Unfortunately,  there  is  considerable  variation  in  the  notation  (and  notational  conventions)  used 
in  the  works  referenced  above:  almost  the  only  common  notational  feature  is  the  use  of  ‘A’  for 
function  abstraction  and  juxtaposition  for  function  application!  The  reader  should  be  prepared  to 
adapt  not  only  to  different  symbols  used  for  the  same  constants  and  operators,  but  also  to  different 
choices  of  what  to  regard  as  primitive  and  what  to  define  as  auxiliary  notation.  (N.B.  the  notation 
presented  and  used  in  this  chapter  is  not  an  accepted  standard.) 

2.6.3  Variations 

The  approach  to  semantics  presented  in  this  chapter,  whose  development  is  sketched  above,  may  be 
regarded  as  the  main  theme  of  Denotational  Semantics:  abstract  syntax,  domains  of  denotations, 
semantic  functions  defined  by  semantic  equations  using  A-notation.  Some  significant  variations  on 
this  theme  are  indicated  below. 

Initial  Algebra  Semantics 

(This  approach  was  sketched  in  Sections  2.2  and  2.3.)  Initial  Algebra  Semantics  was  developed 
by  Joseph  Goguen,  Jim  Thatcher,  Eric  Wagner,  and  Jesse  Wright  [15].  Although  it  is  formally 
equivalent  to  denotational  semantics,  it  has  the  advantage  of  making  it  explicit  that  abstract 
syntax  is  an  initial  algebra,  and  that  semantic  functions  are  homomorphic.  Explicit  structural 
induction  proofs  in  denotational  semantics  can  here  be  replaced  by  appeals  to  initialitv.  It  is  easy 
to  extend  Initial  Algebra  Semantics  to  continuous  algebras,  so  as  to  allow  infinite  programs,  whereas 
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with  denotational  semantics,  abstract  syntax  has  to  be  changed  from  sets  to  epos.  An  additional 
benefit  of  Initial  Algebra  Semantics  is  that  one  always  names  the  domains  of  denotations;  this 
seems  to  encourage  the  specification  of  denotations  as  compositions ,  rather  than  as  applications 
and  abstractions  (but  this  is  only  a  matter  of  style).  Initial  Algebra  Semantics  has  not  yet  been 
applied  to  real  programming  languages. 

The  French  school  of  Algebraic  Semantics  [17]  has  concentrated  on  the  semantics  of  program 
schemes,  rather  than  of  particular  programming  languages.  (See  [9].) 

OBJ 

Goguen  and  Kamran  Parsaye-Ghomi  show  in  [14]  how  the  algebraic  specification  language  ObjT 
(a  precursor  of  Obj2  [13])  can  be  used  to  give  modular  semantic  descriptions  of  programming 
languages.  Their  framework  is  first-order,  and  not  strictly  compositional;  but  higher-order  algebras, 
which  give  the  power  of  A- notation  in  an  algebraic  framework  [39,  42,  12],  could  be  used  instead  of 
Obj,  with  similar  modularity. 

Despite  the  use  of  explicit  modules,  the  semantic  equations  given  by  Goguen  and  Parsaye-Ghomi 
are  still  sensitive  to  the  functionality  of  denotations.  The  approach  has  not  been  applied  to  real 
programming  languages. 

VDM 

The  Vienna  Development  Method,  VDM  [5],  has  an  elaborate  notation,  called  Meta-IV,  that  can 
be  used  to  give  denotational  descriptions  of  programming  languages.  Although  there  are  quite  a 
few  variants  of  Meta-IV,  these  share  a  substantial,  partly-standardized  auxiliary  notation  that 
provides  a  number  of  useful  “flat”  domain  constructors  (e.g.,  sets,  maps)  and  declarative  and 
imperative  constructs  (e.g.,  let-constructions,  storage  allocation,  sequencing,  exception-handling). 
However,  this  auxiliary  notation  is  a  supplement  to,  rather  than  a  replacement  for,  the  A-notation. 
The  foundations  of  Meta-IV  have  been  investigated  by  Stoy  [51]  and  Brian  Monahan  [27]. 

In  contrast  to  Denotational  Semantics,  VDM  avoids  the  use  of  high-order  functions  and  non- 
strict  abstractions,  in  order  to  keep  close  to  the  familiar  objects  of  conventional  programming. 
(Andrzej  Blikle  and  Andrzej  Tarlecki  [7]  went  even  further,  and  advocated  avoidance  of  reflexive 
domains.)  But  as  in  Denotational  Semantics,  there  are  severe  problems  with  large-scale  descriptions, 
due  to  the  lack  of  modularity.  The  fact  that  it  has  been  possible  to  develop  semantic  descriptions  of 
real  programming  languages  such  as  Chill  [8]  and  Ada  [6]  in  (extended  versions  of)  Meta-IV  is  a 
tribute  to  the  discipline  and  energy  of  their  authors,  rather  than  evidence  of  an  inherent  superiority 
of  Meta-IV  over  Denotational  Semantics. 

Action  Semantics 

Action  Semantics  [38,  37,  33,  60,  35,  32]  is  something  of  a  mixture  of  the  denotational,  algebraic, 
and  operational  approaches  to  formal  semantics.  It  has  been  under  development  since  1977,  by 
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the  present  author  and  (since  1984)  David  Watt.  A  brief  summary  of  the  main  features  of  Action 
Semantics  is  given  below. 

The  primary  aim  is  to  make  it  easier  to  deal  with  semantic  descriptions  of  “real”  programming 
languages.  Factors  that  have  been  addressed  include  modularity  (to  obtain  ease  of  modification, 
extension,  and  re-use)  and  notation  (to  improve  comprehensibility). 

Action  Semantics  is  compositional,  just  like  Denotations!  Semantics.  The  essential  difference 
between  Action  Semantics  and  Denotational  Semantics  concerns  the  entities  that  are  taken  as  the 
denotations  of  program  phrases:  so-called  “actions”,  rather  than  functions  on  semantic  domains. 
Actually,  some  actions  do  correspond  closely  to  functions,  and  are  determined  purely  by  the  re¬ 
lation  between  the  “information”  that  they  receive  and  produce.  But  other  actions  have  a  more 
operational  essence:  they  process  information  gradually,  and  they  may  interfere  (or  collaborate) 
when  put  together. 

The  standard  notation  for  actions  is  polymorphic,  in  that  actions  may  be  combined  without 
regard  to  what  “kind”  of  information  they  process:  transient  or  stored  data,  bindings,  or  communi¬ 
cations.  Furthermore,  the  different  kinds  of  information  are  processed  independently.  This  allows 
the  semantic  equations  for  (say)  arithmetical  expressions  to  stay  the  same,  even  when  expressions 
might  be  polluted  with  “side-effects”  or  communications. 

The  fundamental  concepts  of  programming  languages  (as  identified  by  Strachey,  and  implicit 
in  most  denotational  descriptions)  can  be  expressed  straightforwardly  in  action  notation.  The 
comprehensibility  of  action  semantic  descriptions  is  enhanced  by  the  use  of  suggestive  words,  rather 
than  (to  programmers)  cryptic  mathematical  symbols:  in  the  usual  concrete  representation  of  action 
notation,  for  example,  the  action  combinator  expressing  sequential  performance  is  written  as  infixed 
‘then’.  The  notation  is  claimed  to  be  a  reasonable  “compromise”  between  previous  formal  notations 
and  informal  English. 

The  theory  of  actions  includes  some  pleasant  algebraic  laws.  However,  the  basic  understanding 
of  actions  is  operational,  and  action  equivalence  is  defined  by  a  (structural)  operational  seman¬ 
tics  [32].  Action  notation  may  also  be  defined  denotationally,  and  used  as  auxiliary  notation  in 
conventional  denotational  descriptions,  as  illustrated  in  [34]. 

At  the  time  of  writing,  it  is  not  apparent  whether  Action  Semantics  will  turn  out  to  be  any 
more  palatable  than  Denotational  Semantics  to  the  programming  community. 
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